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I. 41.37(C)(1)(I) Real Party of Interest 

The real party of interest in this appeal is the assignee Tokyo Electron Limited whose 
address is Akasaka Biz Tower, 3-1, Akasaka 5-chome, Minato-ku, Tokyo 107-6325, Japan. 

II. 41.37(C)(1)(H) Related Appeals and Interferences 

There are no related interferences. There are related appeals filed or to be filed in 
U.S. Serial Nos. 10/673,138; 10/673,467; 10/673,506; 10/673,507; and 10/673,583. 

III. 41.37(C)(1)(III) Status of Claims 

Claims 1-44 and 48-50 are pending and appealed. Claims 45-47 and 51 are canceled. 

Claim 1 stands provisionally rejected on the ground of nonstatutory obviousness-type 
double patenting as being unpatentable over Claim 1 copending Application No. 10/673,583; 
Claim 1 stands provisionally rejected under the judicially created doctrine of obviousness- 
type double patenting as being unpatentable over Claim 1 of copending Application No. 
10/673,138; Claim 1 stands provisionally rejected under the judicially created doctrine of 
obviousness-type double patenting as being unpatentable over Claim 1 of copending 
application No. 10/673,507; Claims 1-51 stand rejected under 35 U.S.C. § 1 12, first 
paragraph, as based on a disclosure which is not enabling, Claims 1-51 stand rejected under 
35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,802,045 issued to 
Sonderman et al in view of IEEE article "Mathematic-physical engine: parallel processing 
for modeling and simulation of physical phenomena" by Jain et al . 

IV. 41.37(c)(l)(iv) Status of Amendments 

An amendment was filed for this application on November 2, 2007 which resulted in 
the final Office Action dated February 27, 2008. An amendment after the final rejection was 
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filed on May 27, 2008 canceling Claims 45-47 and 51. A terminal disclaimer was also filed 
on May 27, 2008. The terminal disclaimer was approved June 2, 2008. 

V. 41.37(c)(l)(v) Summary of Claimed Subject Matter 

Claim 1, the first of the independent claims appealed, will be treated as a picture 
claim representing many of the features in the remaining independent claims. Accordingly, a 
claim chart for support is provided below showing support from the specification for the 
claim elements. 

In short, Claim 1 defines a method of controlling a process performed by a 
semiconductor processing tool. The method inputs process data relating to an actual process 
being performed by the semiconductor processing tool, and inputs a first principles physical 
model including a set of computer-encoded differential equations. The first principles 
physical model describes at least one of a basic physical or chemical attribute of the 
semiconductor processing tool. The method performs first principles simulation/or the 
actual process being performed during performance of the actual process using the 
physical model to provide a first principles simulation result in accordance with the process 
data relating to the actual process being performed in order to simulate the actual process 
being performed. The first principles simulation result is produced in a timeframe shorter 
in time than the actual process being performed. The model uses the simulation result as 
part of a data set that characterizes the actual process being performed by the semiconductor 
processing tool. 

Accordingly, Claim 1 makes clear that a first principles simulation result for the 
actual process being performed during performance of the actual process is used as part of 
a data set that characterizes the actual process being performed by the semiconductor 
processing tool. The following is a claim chart comparison of the claim elements to the 
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disclosure in the specification. Emphasis has been added for convenience in some of the 
longer passages from the specification. 


Claim 1 

Support in U.S. Pat Appl. No. 10/673,501 

A method of controlling a process 
performed by a semiconductor 
processing tool, comprising 

Specification, numbered paragraph [001 11: One aspect of 

the present invention is a method of facilitating a process 
performed by a semiconductor processing tool, which 
includes inputting data relating to a process performed by 
the semiconductor processing tool, and inputting a first 
principles physical model relating to the semiconductor 
processing tool. First principles simulation is then 
performed using the input data and the physical model to 
provide a simulation result for the process performed by 
the semiconductor processing tool, and the simulation 
result is used as part of a data set that characterizes the 
process performed by the semiconductor processing tool. 
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inputting process data relating to 
an actual process being performed 
by the semiconductor processing 
tool 


Specification, numbered paragraph ["00321: Data input 
device 104 is a device for collecting data relating to a 
process performed by the semiconductor processing tool 
102 and inputting the collected data to the first 
principles simulation processor 106. . . . In one 
embodiment, the data input device 104 may be 
implemented as a physical sensor for collecting data 
about the semiconductor processing tool 102 itself, and/or 
the environment contained within a chamber of the tool. 
Such data may include fluid mechanic data such as gas 
velocities and pressures at various locations within the 
process chamber, electrical data such as voltage, current, 
and impedance at various locations within the electrical 
system of the process chamber, chemical data such as 
specie concentrations and reaction chemistries at various 
locations within the process chamber, thermal data such 
as gas temperature, surface temperature, and surface heat 
flux at various locations within the process chamber, 
plasma processing data (when plasma is utilized) such as 
a plasma density (obtained, for example, from a 
Langmuir probe), an ion energy (obtained, for example, 
from an ion energy spectrum analyzer), and mechanical 
data such as pressure, deflection, stress, and strain at 
various locations within the process chamber. 

Specification, numbered paragraph |"00391: FIG. 2 is a 


flow chart showing a process for using first principles 
simulation techniques to-facilitate a process performed by 
a semiconductor processing tool in accordance with an 
embodiment of the present invention. The process shown 
in FIG. 2 may be run on the first principles simulation 
processor 104 of FIG. 1, for example. As seen in FIG. 2, 
the process begins in step 201 with the inputting of data 
related to a process performed by the semiconductor 
processing tool 102. As discussed above, the input data 
may be data relating to physical attributes of the tool/tool 
environment and/or data relating to a process performed 
by the tool on a semiconductor wafer or results of such 
process. As also described above, the input data may be 
directly input from a physical sensor or metrology tool 
coupled to the first principles simulation processor 104, 
or indirectly input from a manual input device or 
database. 
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inputting a first principles physical 
model including a set of computer- 
encoded differential equations, the 
first principles physical model 
describing at least one of a basic 
physical or chemical attribute of 
the semiconductor processing tool; 


Specification, numbered paragraph [00351: First 


principles physical model 106 is a model of the physical 
attributes of the tool and tool environment as well as the 
fundamental equations necessary to perform first 
principles simulation and provide a simulation result for 
facilitating a process performed by the semiconductor 
processing tool. Thus, the first principles physical model 
106 depends to some extent on the type of semiconductor 
processing tool 102 analyzed as well as the process 
performed in the tool For example, the physical model 
106 may include a spatially resolved model of the 
physical geometry of the tool 102, which is different, for 
example, for a chemical vapor deposition (CVD) chamber 
and a diffusion furnace. Similarly, the first principles 
equations necessary to compute flow fields are quite 
different than those necessary to compute temperature 
fields. The physical model 106 may be a model as 
implemented in commercially available software, such as 
ANSYS, of ANSYS Inc., Southpointe, 275 Technology 
Drive Canonsburg, Pa. 15317, FLUENT, of Fluent Inc., 
10 Cavendish Conn. Centerra Park, Lebanon, N.H. 
03766, or CFD-ACE+, of CFD Research Corp., 215 
Wynn Dr., Huntsville, Ala. 35805, to compute flow 
fields, electromagnetic fields, temperature fields, 
chemistry, surface chemistry (i.e. etch surface chemistry 
or deposition surface chemistry). However, special 
purpose or custom models developed from first principles 
to resolve these and other details within the processing 
system may also be used. 

Specification, numbered paragraph [00361: First 


principles simulations in the present invention include, 
3Ut are not limited to, simulations of electro-magnetic 
fields derived from Maxwell's equations, continuum 
simulations, for example, for mass, momentum, and 
energy transport derived from continuity, the Navier- 
Stokes equation and the First Law of Thermodynamics, 
as well as atomistic simulations derived from the 
Boltzmann equation, such as for example Monte Carlo 
simulations of rarefied gases (see Bird, G. A. 1994. 
Molecular gas dynamics and the direct simulation of gas 
flows, Clarendon Press). 
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performing first principles 
simulation for the actual process 
being performed during 
performance of the actual process 
using the physical model 


Specification, numbered paragraph TOO 121: A first 


principles simulation processor is configured to input a 
first principles physical model relating to the 
semiconductor processing tool, and perform first 
principles simulation using the input data and the physical 
model to provide a first principles simulation result. The 
first principles simulation result is used as part of a data 
set that characterizes the process performed by the 
semiconductor processing tool. 

Specification, numbered paragraph F00361: First 


principles simulation processor 108 is a processing device 
that applies data input from the data input device 104 to 
the first principles physical model 108 to execute a first 
principles simulation. Specifically, the first principles 
simulation processor 108 may use the data provided by 
the data input device 104 to set initial conditions and/or 
boundary conditions for the first principles physical 
model 106, which is then executed by the simulation 
module. 

Specification, numbered paragraph [0057]: In this 


embodiment, steady-state simulations are repeatedly run 
concurrently with the process by using the physical sensor 
measurements to repeatedly update boundary conditions 
of the first principles simulation model. 


to provide a first principles 
simulation result in accordance 
with the process data relating to the 
actual process being performed in 
order to simulate the actual process 
being performed, 


Specification, numbered paragraph [00361: The output of 


the first principles simulation processor 108 is a 
simulation result that is used to facilitate a process 
performed by the semiconductor processing tool 102. For 
example, the simulation result may be used to facilitate 
process development, process control and fault detection 
as well as to provide virtual sensor outputs that facilitate 
tool processes, as will be further described below. 


-6- 


U.S. Serial No. 10/673,501 

Appeal of Office Action dated February 27, 2008 


said first principles simulation 
result being produced in a time 
frame shorter in time than the 
actual process being performed; 
and 


Specification, numbered paragraph [00411: In step 205, 


the first principles simulation processor 108 uses the 
input data of step 201 and the first principles physical 
model of step 203 to execute a first principles simulation 
and provide a simulation result. Step 205 may be 
performed either concurrently with or not concurrently 
with the process performed by the semiconductor 
processing tool. For example, simulations that can be 
performed at short solution times may be run 
concurrently with a tool process, and results used to 
control the process. More computationally intensive 
simulations may be performed not concurrently with the 
tool process and the simulation result may be stored in a 
library for later retrieval. In one embodiment, step 205 
includes using the input data of step 201 to set initial 
and/or boundary conditions for the physical model 
provided in step 205. 

Specification, numbered paragraph [0057]: In this 


embodiment, steady-state simulations are repeatedly run 
concurrently with the process by using the physical sensor 
measurements to repeatedly update boundary conditions 
of the first principles simulation model. 
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Specification, numbered paragraph [0012]: The 
simulation result is used as part of a data set that 
characterizes the process performed by the semiconductor 
processing tool. 

Specification, numbered paragraph [0042]: Once the 
simulation is executed, the simulation result is used to 
facilitate a process performed by the semiconductor 
processing tool 102. As used herein, the term "facilitate a 
process performed by the semiconductor processing tool" 
includes using the simulation result for example to detect 
a fault in the process, to control the process, to 
characterize the process for manufacturing runs, to 
provide virtual sensor readings relating to the process, or 
any other use of the simulation result in conjunction with 
facilitating a process performed by the semiconductor 
processing tool 102. 

Specification, numbered paragraph [0048]: The present 
inventors have also discovered that the network 
architecture of FIG. 3 provides the ability to distribute 
model results done at one processing tool 102 for one 
condition set, to other similar or identical tools operating 
later under the same or similar conditions, so redundant 
simulations are eliminated. Running simulations only for 
unique processing conditions at on-tool and standalone 
modules and re-using results from similar tools that have 
already known simulated solutions allows for rapid 
development of lookup libraries containing results that 
can be used for diagnostics and control over a large range 
of processing conditions. Further, the reuse of the known 
solutions as initial conditions for first principles 
simulation reduces the computational requirements and 
facilitates the production of simulated solutions in a time 
frame consistent with on-line control. Similarly, the 
network architecture of FIG. 3 also provides the ability to 
propagate changes and refinements made to physical 
models and model input parameters from one simulation 
module to others in the network. For example, if during 
process runs and parallel executions of a model it is 
determined that some input parameters need to be 
changed, then these changes can be propagated to all 
other simulation modules and tools via the network. 


Claim 23 defines a system which is similar to the method of Claim 1 . Thus, the 


using the simulation result as part 
of a data set that characterizes the 
actual process being performed by 
the semiconductor processing tool. 
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features of Claim 23 are supported in the specification by numbered paragraphs [001 1], 
[0012], [0032]. [0035], [0036], [0039], [0041], [0042], [0048], and [0057]. 

Claim 48 defines at least one of non- volatile media and volatile media containing 
program instructions for execution on a processor, which is similar to method Claim 1. Thus, 
the features of Claim 48 are supported in the specification by numbered paragraphs [001 1], 
[0012], [0032]. [0035], [0036], [0039], [0041], [0042], [0048], and [0057]. 

VI. 41.37(C)(1)(VI) Grounds of Rejection for Review 

Whether the rejection of Claim 1 under the judicially created doctrine of obviousness- 
type double patenting over Claim 1 of U.S. Pat. Appl. No. 10/673,583 (the '583 application) 
should be reversed. Whether the rejection of Claim 1 under the judicially created doctrine of 
obviousness-type double patenting over Claim 1 of U.S. Pat. Appl. No. 10/673,138 (the '138 
application) should be reversed. Whether the rejection of Claim under the judicially created 
doctrine of obviousness-type double patenting over Claim 1 of U.S. Pat. Appl. No. 
10/673,507 (the '507 application) should be reversed. Whether the rejection of Claims 1-44 
and 48-50 under 35 U.S.C. § 1 12, first paragraph, as being based on a non-enabling 
disclosure should be reversed. Whether the rejection of Claims 1-44 and 48-50 under 
35 U.S.C. § 103(a) as being unpatentable over Sonderman et al in view of Jain et al should be 
reversed. 

VII. 41.37(C)(1)(VII) ARGUMENTS 

A. Regarding the 35 USC 112 1 st Paragraph Rejection of Claims 1-44 
and 48-50 
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Briefly recapitulating, Claim 1 defines a method of controlling a process performed by a 
semiconductor processing tool, including: 

1) inputting process data relating to an actual process being performed 
by the semiconductor processing tool, 

2) inputting a first principles physical model including a set of 
computer-encoded differential equations, the first principles physical model 
describing at least one of a basic physical or chemical attribute of the 
semiconductor processing tool, 

3) performing first principles simulation for the actual process being 
performed during performance of the actual process using the physical 
model to provide a first principles simulation result in accordance with the 
process data relating to the actual process being performed in order to simulate 
the actual process being performed, said first principles simulation result 
being produced in a time frame shorter in time than the actual process being 
performed, and 

4) using the simulation result as part of a data set that characterizes the 
actual process being performed by the semiconductor processing tool.. 

The claim defines clearly a process where data input from an actual process being performed 
is used for producing a first principles simulation result, produced for the actual process being 
performed during performance of the actual process. The result obtained is produced in a 
time frame shorter in time than the actual process being performed. The result obtained is 
then used as part of a data set that characterizes the actual process being performed by the 
semiconductor processing tool. M.P.E.P. 2164.01 states that the test of enablement is 
whether one reasonably skilled in the art could make or use the invention from the disclosures 
in the patent coupled with information known in the art without undue experimentation. 
Appellant submits that details of 1) inputting the process data and 2) inputting the first 
principles physical model including what basic physical and chemical attribute of the 
semiconductor processing tool are used are disclosed in Appellant's filed specification. For 
instance, details of inputting data are given for example at numbered paragraphs [0032] and 
[0033], which state: 
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Data input device 104 is a device for collecting data relating to a process 
performed by the semiconductor processing tool 102 and inputting the 
collected data to the first principles simulation processor 106. The process 
performed by the semiconductor process tool 102 may be a characterization 
process (i.e. process design or development), a cleaning process, a production 
process, or any other process performed by the semiconductor processing tool. 
In one embodiment, the data input device 104 maybe implemented as a 
physical sensor for collecting data about the semiconductor processing tool 
102 itself, and/or the environment contained within a chamber of the tool. 
Such data may include fluid mechanic data such as gas velocities and 
pressures at various locations within the process chamber, electrical data such 
as voltage, current, and impedance at various locations within the electrical 
system of the process chamber, chemical data such as specie concentrations 
and reaction chemistries at various locations within the process chamber, 
thermal data such as gas temperature, surface temperature, and surface heat 
flux at various locations within the process chamber, plasma processing data 
(when plasma is utilized) such as a plasma density (obtained, for example, 
from a Langmuir probe), an ion energy (obtained, for example, from an ion 
energy spectrum analyzer), and mechanical data such as pressure, deflection, 
stress, and strain at various locations within the process chamber. 

In addition to the tool and tool environment data, the data input device 
104 may collect data relating to the process itself, or process results obtained 
on a semiconductor wafer that the tool 102 is performing a process on. In one 
embodiment, data input device 104 is implemented as a metrology tool 
coupled to the semiconductor processing tool 102. The metrology tool may be 
configured to measure process performance parameters such as: etch rate, 
deposition rate, etch selectivity (ratio of the rate at which a first material is 
etched to the rate at which a second material is etched), an etch critical 
dimension (e.g. length or width of feature), an etch feature anisotropy (e.g. 
etch feature sidewall profile), a film property (e.g. film stress, porosity, etc.), a 
mask (e.g. photoresist) film thickness, a mask (e.g. photoresist) pattern critical 
dimension, or any other parameter of a process performed by the 
semiconductor processing tool 102. 

Details of inputting a first principles physical model for performing the first principles 
simulation result are given for example at numbered paragraphs [0035] and [0036] which 
state that: 

First principles physical model 106 is a model of the physical attributes 
of the tool and tool environment as well as the fundamental equations 
necessary to perform first principles simulation and provide a simulation result 
for facilitating a process performed by the semiconductor processing tool. 
Thus, the first principles physical model 106 depends to some extent on the 
type of semiconductor processing tool 102 analyzed as well as the process 
performed in the tool. For example, the physical model 106 may include a 
spatially resolved model of the physical geometry of the tool 102, which is 
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different, for example, for a chemical vapor deposition (CVD) chamber and a 
diffusion furnace. Similarly, the first principles equations necessary to 
compute flow fields are quite different than those necessary to compute 
temperature fields. The physical model 106 may be a model as implemented 
in commercially available software, such as ANSYS, of ANSYS Inc., 
Southpointe, 275 Technology Drive Canonsburg, PA 15317, FLUENT, of 
Fluent Inc., 10 Cavendish Ct. Centerra Park, Lebanon, NH 03766, or CFD- 
ACE+, of CFD Research Corp., 215 Wynn Dr., Huntsville, AL 35805, to 
compute flow fields, electro-magnetic fields, temperature fields, chemistry, 
surface chemistry (i.e. etch surface chemistry or deposition surface chemistry). 
However, special purpose or custom models developed from first principles to 
resolve these and other details within the processing system may also be used. 

First principles simulation processor 108 is a processing device that 
applies data input from the data input device 104 to the first principles 
physical model 108 to execute a first principles simulation. Specifically, the 
first principles simulation processor 108 may use the data provided by the data 
input device 104 to set initial conditions and/or boundary conditions for the 
first principles physical model 106, which is then executed by the simulation 
module. First principles simulations in the present invention include, but are 
not limited to, simulations of electro-magnetic fields derived from Maxwell's 
equations, continuum simulations, for example, for mass, momentum, and 
energy transport derived from continuity, the Navier-Stokes equation and the 
First Law of Thermodynamics, as well as atomistic simulations derived from 
the Boltzmann equation, such as for example Monte Carlo simulations of 
rarefied gases (see Bird, G.A. 1994. Molecular gas dynamics and the direct 
simulation of gas flows, Clarendon Press). First principles simulation 
processor 108 may be implemented as a processor or workstation physically 
integrated with the semiconductor processing tool 102, or as a general purpose 
computer system such as the computer system 1401 of Figure 14. The output 
of the first principles simulation processor 108 is a simulation result that is 
used to facilitate a process performed by the semiconductor processing tool 
102. For example, the simulation result may be used to facilitate process 
development, process control and fault detection as well as to provide virtual 
sensor outputs that facilitate tool processes, as will be further described below. 


Thus, one of ordinary skill in the art, from the detailed information provided in the 
specification as to the data input and as to the commercially availability of software 
programs, would not have to use undue experimentation to apply the respective physical 
attributes that each model is tailored to accept in order to perform the claimed inputting a first 
principles physical model step. 
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The examiner requested details of the models which lead to the unexpected result of 

being able to avoid the lengthy time conventionally required for the generation of a first 

principles model simulation. See page 10 of the Office Action. Appellant points out the 

procedures by which the unexpected results of the invention are achieved. It is not the details 

of the models, but rather the details as to how the model calculations are implemented which 

reduce the time for calculations. For instance, the disclosed characteristics in the 

specification which permit simulation results to be obtained in a time frame compatible with 

using the first principles model simulation result for real time process control are enumerated 

below with reference to the numbered paragraphs in the filed specification: 

1) the use of interconnected resources inside a semiconductor device 
manufacturing facility to perform the first principles simulation (see 
specification, numbered paragraph [0043] and Figure 3, both reproduced 
below), 

2) the use of code parallelization among interconnected computational 
resources inside the semiconductor device manufacturing facility (see 
specification, numbered paragraphs [0047] and [0048] reproduced below), 

3) the sharing of simulation information among interconnected resources 
inside the semiconductor device manufacturing facility (see specification, 
numbered paragraphs [0047] and [0048] reproduced below), and 

4) the reduction in redundant execution of substantially similar first principles 
simulations by different resources the reuse of known solutions as initial 
conditions for the first principles simulation, as features which used singularly 
or in combination lead to a simulation result in a time frame consistent with 
real time process control in a semiconductor processing tool (see specification, 
numbered paragraphs [0047] and [0048] reproduced below). 
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Figure 3 
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[0043] FIG. 3 is a block diagram of a network architecture that may be 
used to provide first principles simulation techniques to facilitate a process 
performed by a semiconductor processing tool in accordance with an 
embodiment of the present invention. As seen in this figure, the network 
architecture includes a device manufacturing fab connected to remote 
resources via the Internet 314. The device manufacturing fab includes a 
plurality of semiconductor processing tools 102 connected to respective 
simulation modules 302. As described with respect to FIG. 1, each 
semiconductor processing tool 102 is a tool for performing a process related to 
manufacturing a semiconductor device such as an integrated circuit. Each 
simulation module 302 is a computer, workstation, or other processing device 
capable of executing first principles simulation techniques to facilitate a 
process performed by a semiconductor processing tool 102. Thus, each 
simulation module 302 includes the first principles physical model 106 and the 
first principles simulation processor 108 described with respect to FIG. 1, as 
well as any other hardware and/or software that may be helpful for executing 
first principles simulations. Moreover, simulation modules 302 are configured 
to communicate with the fab-level advanced process control (APC) controller 
using any known network communication protocol. Each simulation module 
302 may be implemented as a general purpose computer such as the computer 
system 1401 of FIG. 14. 

[0047] The present inventors have discovered that the network 
configuration of FIG. 3 provides computational and storage resource sharing 
that allows a broad range of first principles simulation results at reasonable 
solution speeds, thus providing meaningful on-tool simulation capabilities that 
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can facilitate processes performed by the tool Specifically, while simple 
simulations may be executed by a tool ? s dedicated simulation module, complex 
simulations requiring greater computational resources maybe executed using 
code parallelization techniques on multiple simulation modules in the network 
that may be on-tool or standalone. Even on-tool simulation modules in 
equipment currently under preventive maintenance may be used as a shared 
computational resource, provided there is power to the simulation module. 
Similarly, simulation results used for later lookup can be stored in libraries 
(e.g. storage devices) anywhere in the fab network, and accessed by all tools 
when lookups of diagnostic or control data are made. 

[0048] The present inventors have also discovered that the network 
architecture of FIG. 3 provides the ability to distribute model results done at 
one processing tool 102 for one condition set, to other similar or identical tools 
operating later under the same or similar conditions, so redundant simulations 
are eliminated. Running simulations only for unique processing conditions at 
on-tool and standalone modules and re-using results from similar tools that 
have already known simulated solutions allows for rapid development of 
lookup libraries containing results that can be used for diagnostics and control 
over a large range of processing conditions. Further, the reuse of the known 
solutions as initial conditions for first principles simulation reduces the 
computational requirements and facilitates the production of simulated 
solutions in a time frame consistent with on-line control. Similarly, the 
network architecture of FIG. 3 also provides the ability to propagate changes 
and refinements made to physical models and model input parameters from 
one simulation module to others in the network. For example, if during 
process runs and parallel executions of a model it is determined that some 
input parameters need to be changed, then these changes can be propagated to 
all other simulation modules and tools via the network. 


Hence, it is respectfully submitted that, in view of the disclosure of commercial 
software available for the different physical models disclosed in the specification and in vie 
of the disclosure of procedures by which the time for producing a first principles model 
simulation result can be reduced, the invention does not require undue experimentation. 

Accordingly, the 35 U.S.C. 1 12, first paragraph, rejection of Claims 1-44 and 48-50 
should be reversed. 
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B. Regarding the 35 USC 103 Rejection of Claims 1-44 and 48 over 
Sonderman et al and Jain et al 

The Office Action makes clear on pages 3 and 4 that the Examiner and the Appellant 
disagree as to whether the subscripts in Sonderman et al Si associated with the silicon wafer 
disclosure refers to process control for the same wafer being processed or process control for 
subsequent wafers. The Examiner's position is that Sonderman et al would have used S i+ i to 
designate subsequent wafers. 

Yet, Appellant respectfully points out that, at col. 9, lines 46-51, Sonderman et al 
specifically states: 

The system 100 then optimizes the simulation (described above) to find more 
optimal process target (TO for each silicon wafer, Sj to be processed. These 
target values are then used to generate new control inputs, Xn on the line 805 
to control a subsequent process of a silicon wafer Si. [Emphasis added] 

The plain reading of this section of Sonderman et al is that the system 100 then (e.g., at time 

Tl) optimizes the simulation for each silicon wafer, S,- to be processed (e.g., later at time T2). 

In other words, the simulation results of Sonderman et al produce a new control input for 

each silicon wafer to be processed. Thus, Appellant respectfully submits that Sonderman et 

al teach performing a simulation result for a process to be performed before performance of 

the actual process, and do not teach the claimed performing first principles simulation/or the 

actual process being performed during performance of the actual process} 

Other sections of Sonderman et al support Appellant's position on this matter that the 

simulation results in Sonderman et al are made prior to controlling a subsequent process. For 

instance, Figure 4 of Sonderman et al (reproduced below) shows that the simulation results 

are produced ahead of performing a process and thus have to be based on historical data. 

1 Appellant also point out that Sonderman et al do not disclose or suggest a first principles 
simulation. 
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Define process task 


41 O 


420 


430 


Perform process simulation function 


Interface simulation with process control 


Perform process based upon interfacing simulation 
with process control 


440 


FIGURE Ar 


With reference to Figure 4, Sonderman et al disclose at col. 6, lines 24-47: 

Turning now to FIG. 4, a flow chart representation of the methods in 
accordance with the present invention is illustrated. In one embodiment, the 
system 100 defines a process task that is to be performed (block 410). The 
process task may be a photolithography process, an etching process, and the 
like. The system 100 then performs a process simulation function (block 
420). A more detailed description of the process simulation function 
described in block 420, is illustrated below. In one embodiment, a simulation 
data set results from the execution of the process simulation function. 

Once the system 100 performs the process simulation function, the 
system 100 performs an interfacing function^ which facilitates interfacing of 
the simulation data with the process control environment 180 (block 430). 
The process control environment 180 can utilize the simulation data in order to 
modify or define manufacturing control parameters that control the actual 
processing steps performed by the system 100. Once the system 100 
interfaces the simulation data with the process control environment 180, the 
system 100 then performs a manufacturing process based upon the 
manufacturing parameters defined by the process control environment 1 80 
(block 440). [Emphasis added] 

Hence, the process flow in Sonderman et al is straightforward: 

1) define a process to be modeled, 

2) model the simulation result, 

3) interface simulation result to processor, and then 
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4) run the process under control based on the pre-existing simulation result. 

In the final Office Action, the examiner disagreed with this interpretation of 

Sonderman et al. On page 6 of the Office Action, the examiner pointed out a part of 

Sonderman et al's disclosure with emphasis added by underscoring which was believed by 

the examiner to support his position on this matter. This characterization is repeated below 

for the sake of convenience with the examiner's emphasis. 

Furthermore, the simulation environment 210 can be used for feedback 
modification of control parameters invoked by the process control 
environment 180. For example, the manufacturing environment 170 can send 
metrology data results into the simulation environment 210. The simulation 
environment 210 can then use the metrology data results and perform various 
tests and calculations to provide more accurate, modified control parameters to 
the process control environment 180. A feedback loop in then completed 
when the process control environment 180 sends the modified or adjusted 
process control parameters to the manufacturing environment 170 for further 
processing of semiconductor wafers. {Examiner's emphasis added.} 

Appellant respectfully points out that this description in Sonderman et al is a 
description of a feedback loop as Sonderman et al describe just below that portion which the 
examiner emphasized. Feedback modification is by definition the control of future wafers 
based on what has already occurred to a previous wafer. Hence, this section supports rather 
than refutes Appellant's position on this matter. 

Accordingly, Appellant respectfully submits that Sonderman et al do not disclose and 
indeed teach away from the present invention where data input from an actual process being 
performed is used for producing a first principles simulation result, which is produced for the 
actual process being performed during performance of the actual process for control of the 
actual process. 

The deficiencies in Sonderman et al are not overcome by Jain et al . The Office Action 
in rejecting the present claims supplements the teachings of Sonderman et al with the 
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teachings of Jain et al for their teaching of computer encoded differential equations in a 

mathematical physical engine (MPE) which can be applied to wafer processing. See Office 

Action, page 16. Jain et al describe at pages 372-373 that: 

We propose a wafer scale implementation of the MPE. The starting point 
would be a dedicated processing cell, optimized specifically for the PDE 
arithmetic and data routing. Because of the relative simplicity of the cell, it is 
expected that extremely large arrays (8x8 to 32x32) could be successfully 
processed on a single piece of silicon using Wafer Scale Integration 
techniques. In fact, we have already laid the foundation for the development 
of such a processing cell. Our Universal Multiply-Subtract-Add [11] could be 
adapted for this first cell design. Similarly, our nonlinear coprocessor cell 
[12]-[14] might be used in conjunction with the UMSA to provide advanced 
mathematical functions. As suggested in Fig. 2, there would be courtyards of 
processors, each with two interconnection networks and two memory banks. 
2-D, 3-D, and 4-D problems could then be mapped for parallel computations. 
Since inter-processor delays are very small (say a few ns), extremely high 
speeds could be achieved. This, together with the high degree of parallelism, 
would result also in high throughout. We envision 100 to 1000 processors (on 
one wafer) forming a wafer scale MPE. At a clock frequency of 50 MHz, a 
single wafer could achieve up to 20 GFLOPs performance. With our nonlinear 
coprocessor added, each instruction could equate to multiple floating point 
operations. 

Furthermore, because of the extendible architecture, several wafers could be 
interconnected as shown in Fig. 5 to construct a "stacked" MPE wafer system 
(SMPE). Note that no vertical interconnects within the stack of wafers are 
expected. Tens to hundreds of GFLOPs performance in a volume the size of a 
desk-top computer [15] could thus be achieved. However, these predictions 
ignore the likely technical advances in the next five years; a tenfold further 
increase in performance might be achievable, [Emphasis Added] 

Thus, as emphasized above, the proposed development work in Jain requires the 

development of futuristic computational equipment which one of ordinary skill in the art 

would be reluctant to implement or utilize for the rigorous standards needed in semiconductor 

manufacturing. 

Appellant's position in this matter is corroborated by Tan et al . attached in the 
Evidence Appendix. Tan et al also teach the use on an existing process model for feedback or 
feed forward processing. In feedback control, by definition, the results of a process step are 


-19- 


U.S. Serial No. 10/673,501 

Appeal of Office Action dated February 27, 2008 


provided to subsequent wafer. In feed forward control, the results of a prior process step are 

used to adjust a subsequent process being run of the wafer. Tan et al describe: 

The illustrative APC Framework 200 includes a process model 202 that 
receives feed-forward and feed-back data and calculates a processing 
parameter. The illustrative portion of the APC Framework 200 includes two 
measurement devices, in particular a pre-process metrology machine 204 and a 
post-processing metrology machine 206. The pre-process metrology machine 
204 performs a measurement on a material prior to processing in a processing 
machine 208 and sends the measurement, as feed- forward data, to the process 
model 202. The processing machine 208 sends processed material to the post- 
processing metrology machine 206 to measure post-process data which is 
sent to the process model 202 as feedback data. 

Referring to FIG. 4, a schematic block diagram shows material flow of a 
processing step 400 of a semiconductor manufacturing process from a process 
engineer perspective. An APC plan 402 retrieves a process model from the 
data store 306, then executes a parameter calculation algorithm 404. The APC 
plan 402 gives the calculated parameters to a machine 406 and directs the 
machine 406 to execute the process. The machine 406 issues a signal to the 
APC plan 402 when the process execution is complete. The APC plan 402 
sends the calculated parameters to the data history store 310 of the historical 
database 312. 

Referring to FIG. 5, a schematic block diagram shows material flow of a post- 
process measurement step 500 of a semiconductor manufacturing process from 
a process engineer perspective. An APC plan 502 sends a message to a 
machine 504 instructing the machine 504 to measure a post-processed 
material. The machine 504 sends measurement data to the APC plan 502. 
The APC plan 502 retrieves an old process model from the data store 306. 
The APC plan 502 executes a model update algorithm 506. The APC plan 
502 stores an updated model in the data store 306 for usage in the 
processing step 400. The APC plan 502 sends new model data to the data 
history store 310 of the historical database 312. [Emphasis added.] 

Thus, Tan et al use post-process data to update a model for a subsequent process step. 

Appellant's position on these matters is also supported by Kee et ah of record in this 
application and attached in the Evidence Appendix. In the outstanding Office Action, the 
examiner indicated that he found no connection or legal basis for considering the teachings of 
Kee et al . Recently published guidelines for the Patent and Trademark Office, published in 
Federal Register Vol. 72, No. 195, on Wednesday October 10, 2007entitled: "Examination 
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Guidelines for Determining Obviousness under 35 U.S.C. 103 in View of the Supreme Court 
Decision in KSR International v. Teleflex Inc," indicate that: 

Office personnel should consider all rebuttal evidence that is timely 
presented by the Applicants when reevaluating any obviousness determination. 
Rebuttal evidence may include evidence of "secondary considerations " such 
as "commercial success, long felt but unsolved needs, [and] failure of others", 
and may also include evidence of unexpected results. Office personnel must 
articulate findings of fact that support the rationale relied upon in an 
obviousness rejection. As a result, Applicants are likely to submit evidence to 
rebut the fact finding made by Office personnel. For example, in the case of a 
claim to a combination, Applicants may submit evidence or argument to 
demonstrate that: 

(1) one of ordinary skill in the art could not have combined the claimed 
elements by known methods (e.g., due to technological difficulties); 

(2) the elements in combination do not merely perform the function 
that each element performs separately; or 

(3) the results of the claimed combination were unexpected. 

Once the Applicant has presented rebuttal evidence, Office personnel 
should reconsider any initial obviousness determination in view of the entire 
record. All the rejections of record and proposed rejections and their bases 
should be reviewed to confirm the continued viability. The Office action 
should clearly communicate the Office's findings and conclusions, articulating 
how the conclusions are supported by the findings. [Emphasis Added.] 

M.P.E.P. § 2143.01(H) indicates that all teachings in the prior art must be considered. 
M.P.E.P. 2141.03 indicates that the examiner must ascertain what would have been obvious 
to one of ordinary skill in the art at the time of the invention. Hence, for all these legal 
considerations, Kee et al is presented as rebuttal evidence for the non-obviousness of the 
claims. 

Specifically, the prior art Kee et al reference is evidence of the technological 
difficulties involved in producing a first principles model simulation result and, under the 
published guidelines, should be considered. The prior art Kee et al reference represents what 
one of ordinary skill in the art would have known and would have expected at the time of the 
invention and, under the M.P.E.P., should be considered. 
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Kee et al deal with the process control of a Rapid Thermal Processing (RTP) tool and 
do not use real time modeling. RTP tools are tools used in semiconductor manufacturing. 
Kee et al in detail disclose that: 

The modeling apparatus 101 of the instant invention may also be used 
to perform an inverse analysis to establish the boundary conditions or 
parameter values required to achieve a certain function of the thermal system. 
This allows the apparatus to be used to establish the appropriate process 
parameters and boundary conditions for the thermal system modeled. In 
accordance with the instant invention, the inverse analysis can be directly 
carried out by the modeling apparatus rather than using the conventional 
approach, which merely solves the direct problem repeatedly, in a lengthy 
and costly iterative process, to determine appropriate input parameters to 
achieve a desired result. In other words, in accordance with the instant 
invention, once a particular thermal process is modeled for a particular set 
of control parameters, the device may then be used to automatically obtain the 
necessary control parameters to achieve a desired result by providing the 
modeling apparatus with parameters corresponding to the desired result. 

To carry out the inverse analysis, the modeling apparatus 101 includes 
an inverse parameter input section 104 also connected to input device 103. A 
user inputs into the modeling apparatus 101 parameters corresponding to 
desired results, e.g., desired temperature characteristics of the system, which 
are stored in memory 108. The processing unit 110, under control of modeling 
program 111, uses the previously generated model of the thermal system and 
the parameters held in memory 108 and derives or predicts particular control 
parameters to meet the constraints entered through the inverse parameter input 
section 104. This process is more fully described below in connection with the 
examples provided. 2 [Emphasis added.] 

Hence, Kee et al explicitly disclose that a previously generated model of the thermal system 
is used to design and control the thermal system. Kee et al exemplify the difficulties of a 
"conventional approach" which solves spectral radiation transport equations through "a 
lengthy and costly iterative process." These problems forced Kee et al to use pre-generated 
model results for a control process of a RTP process. 

The examiner in the final Office Action did not apply but rather noted the IEEE 1990 
paper by Su-shing Chen, "AEMPES: An expert system for in-situ diagnostics and process 


2 Kee et al, col. 4, lines 21-50. 
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monitoring," hereinafter referred to as AEMPS, as evidence that the most recently added 
limitation (said first principles simulation result being produced in a time frame shorter in 
time than the actual process being performed) is known in the art. Yet, AEMPS describes the 
use of simulation in neural network environment used to "learn processes and the equipment 
model." See page 120, section 4. AEMPS describes in section 4 that "a rule-based expert 
system provides human interfaces and high-level decision support." Accordingly, AEMPS 
does not describe a first principles simulation result, but rather describes a neural network 
learning-based simulation. Accordingly, a system such as in AEMPS which learns a behavior 
and establishes rules based on the behavior would be used in a feedback control (see section 4 
of AEMPS) . Such a system would not 1) produce a first principles simulation result or 2) 
produce a first principles simulation result during the performance of the actual process to 
control the actual process performed by the semiconductor processing tool. 

Moreover, AEMPS describes in section 2 (regarding manufacturing automation) that 
it is not known how to couple computer aided design, the integration of a manufacturing line, 
and its simulator together, and that it is not known how "to complete integration of 
manufacturing lines with their simulators." Hence, like Jain et al , AEMPS describes a 
futuristic system under development. Even if for the sake of argument it were supposed that 
the AEMPS system was a first principles simulation result (which it is not), one of ordinary 
skill in the art would be reluctant to implement or utilize the AEMPS system for the rigorous 
standards needed in semiconductor manufacturing. 

The examiner in the final Office Action also noted appellant's disclosure at numbered 
paragraphs [0004] and [0005] in the specification as an apparent admission that the feature of 
a first principles simulation result being produced in a time frame shorter in time than the 
actual process being performed was a feature known in the art. Yet, the specification 
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describes this material as being background material and makes no indication that what the 
present inventors recognized and described in the background section was known to others or 
would in any other way qualify as 35 U.S.C. § 102 prior art. 

More importantly, numbered paragraphs [0004] and [0005] indicate at most that the 
times for a large number of simulations typically done in the tool design stage are 
comparable to wafer or wafer cassette processing times. There is no statement here regarding 
how long the times would be for a process control simulation. Further, numbered paragraphs 
[0004] and [005] indicate that, at the time of the invention, there were serious impediments 
which would mean that it would not be possible, prior to the invention, to produce a first 
principles simulation result in a time frame shorter in time than the actual process being 
performed. 

[0004] These industry and manufacturing challenges have led to interest in 
more use of computer based modeling and simulation in the semiconductor 
manufacturing industry. Computer-based modeling and simulation are 
increasingly being used for prediction of tool performance during the 
semiconductor manufacturing tool design process. The use of modeling 
allows the reduction of both cost and time involved in the tool development 
cycle. Modeling in many disciplines, such as stress, thermal, magnetics, etc., 
has reached a level of maturity where it can be trusted to provide accurate 
answers to design questions. Moreover, computer power has been increasing 
rapidly along with the development of new solution algorithms, both of which 
resulted in reduction of time required to obtain a simulation result. Indeed, 
the present inventors have recognized that a large number of simulations 
typically done in the tool design stage can presently be run in times 
comparable to wafer or wafer cassette processing times. These trends have 
led to the suggestion that simulation capability typically used only for tool 
design can be implemented directly on the tool itself to aid in various 
processes performed by the tool. For example, the 2001 International 
Technology Roadmap for Semiconductors identifies issues impeding the 
development ofon-tool integrated simulation capability as an enabling 
technology for manufacturing very small features in future semiconductor 
devices. 

[0005] Indeed, the failure of industry to implement on-tool simulation to 
facilitate tool processes is primarily due to the need for computational 
resources capable of performing the simulations in a reasonable time. 

Specifically, the processor capabilities currently dedicated to semiconductor 
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manufacturing tools are typically limited to diagnostic and control functions, 
and therefore could only perform relatively simple simulations. Thus, the 
semiconductor manufacturing industry has perceived a need to provide 
powerful dedicated computers in order to realize meaningful on-tool 
simulation capabilities. However, dedication of such a computer to the 
semiconductor processing tool results in wasted computational resources when 
the tool runs processes that use simple simulations, or no simulations at all. 
This inefficient use of an expensive computational resource has been a major 
impediment to implementation of simulation capabilities on semiconductor 
processing tools. [Emphasis added.] 

Hence, Tan et al, Jain et al, Kee et al, AEMPES . and the background section of the 
specification all discredit any suggestion that the examiner may have read from the disclosure 
of Sondermanet al for real-time simulation and control of an actual process being performed. 

The Supreme Court in KSR International Co. v. Teleflex Inc. et al 2007 U.S. LEXIS 

4745 reinforced the role of Graham factors, teaching away and elements working together in 

an unexpected and fruitful manner in deciding obviousness. The Court stated that: 

In United States v. Adams, 383 U. S. 39, 40 (1966), a companion case 
to Graham, the Court considered the obviousness of a wet battery that varied 
from prior designs in two ways: It contained water, rather than the acids 
conventionally employed in storage batteries; and its electrodes were 
magnesium and cuprous chloride, rather than zinc and silver chloride. The 
Court recognized that when a patent claims a structure already known in the 
prior art that is altered by the mere substitution of one element for another 
known in the field, the combination must do more than yield a predictable 
result. 383 U. S., at 50-51. It nevertheless rejected the Government's claim 
that Adams's battery was obvious. The Court relied upon the corollary 
principle that when the prior art teaches away from combining certain known 
elements, discovery of a successful means of combining them is more likely to 
be nonobvious. Id., at 51-52. When Adams designed his battery, the prior art 
warned that risks were involved in using the types of electrodes he employed. 
The fact that the elements worked together in an unexpected and fruitful 
manner supported the conclusion that Adams's design was not obvious to 
those skilled in the art. [Emphasis added.] 

In the present situation, the claimed elements worked together in an unexpected and 
fruitful manner as compared to the prior art. For example, since in Sonderman et al there 
are new control inputs for each subsequent wafer, one can not compensate for real time 
excursions from the existing model occurring while the wafer is being processed. In other 
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words, the historically lengthy time for generation of a first principles model simulation 
would mean that, in Sonderman et al , one is prevented from realizing a real time process 
control based on a first principles simulation during the actual process being performed. 
Meanwhile, the claimed processes and systems (by producing a first principles simulation 
result in a time frame shorter in time than the actual process being performed) permits 
accurate control of the process even if the system being controlled deviates from its historical 
behavior. 

For all these reasons, Appellant submits that independent Claims 1, 23, and 48 
patentably define over Sonderman et al and Jain et al and Tan et al . 

Hence, the 35 U.S.C. § 103(a) rejection of Claims 1-44 and 48 as being unpatentable 
over Sonderman et al in view of Jain et al should be reversed. 

C. Regarding the 35 USC 103 Rejection of Claims 49 and 50 over 
Sonderman et al and Jain et al 

Claim 49 defines that the performing a first principles simulation includes providing 
for the first principles simulation a reuse of known solutions as initial conditions for the first 
principles simulation. The Office Action notes that "Jain teaches use of Navier Stokes and 
other known simulation solutions" and cites pp. 367-368 of Jain et al . However, the Navier 
Stokes equation on page 367 of Jain et al is a fluid flow equation which needs boundary 
conditions and which need s to be solved in order to produce a solution. The Navier Stokes 
equation on page 367 of Jain et al does not represent a solution, much less the reuse of 
known solutions as initial conditions for the first principles simulation. Appellant's 
inspection of the remainder of Jain et al finds no disclosure of the reuse of known solutions as 
initial conditions for the first principles simulation. 

Hence, for this additional reason (besides their dependence from allowable claims), 
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the 35 U.S.C. § 103(a) rejection of Claims 49 and 50 as being unpatentable over Sonderman 
et al in view of Jain et al should be reversed. 

D. Regarding the Double Patenting Rejections 

1. The Double Patenting Rejection over the '583 Application 

The filed terminal disclaimer addressed this issue. Hence, Appellant has 
overcome the double patenting rejection. 

2. The Double Patenting Rejection over the '138 Application 

The filed terminal disclaimer addressed this issue. Hence, Appellant has 
overcome the double patenting rejection. 

3. The Double Patenting Rejection over the '507 Application 

The filed terminal disclaimer addressed this issue. Hence, Appellant has 
overcome the double patenting rejection. 

VII. 41.37(c)(l)(vii) Claims Appendix Of Claims Involved In Appeal 

Attached herewith is a Claims Appendix. 

IX. 41.37(C)(1)(IX) Evidence Appendix 

Included in the appendix is a copy of Tan et al (U.S. Pat. No. 6,263,255). 

Included in the appendix is a copy of Keeetal (U.S. Pat. No. 5,583,780). 

Included in the appendix is a copy of Su-shing Chen, "AEMPES: An expert system 
for in-situ diagnostics and process monitoring," referred to by the examiner, but not applied, 
in the Office Action of February 7, 2008. 
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X. 


41.37(c)(l)(x) Related Proceedings Appendix 


There are no related proceedings. 


XI. 


Conclusion 


Appellant request on the basis of the arguments presented above that the outstanding 


grounds for the rejection be reversed. Appellant submits that the application is in condition 


for allowance. 
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CLAIMS APPENDIX 

1 . A method of facilitating a process performed by a semiconductor processing tool, 
comprising: 

inputting process data relating to an actual process being performed by the 
semiconductor processing tool; 

inputting a first principles physical model including a set of computer-encoded 
differential equations, the first principles physical model describing at least one of a basic 
physical or chemical attribute of the semiconductor processing tool; 

performing first principles simulation for the actual process being performed using the 
physical model to provide a first principles simulation result in accordance with the process 
data relating to the actual process being performed in order to simulate the actual process 
being performed, said first principles simulation result being produced in a time frame shorter 
in time than the actual process being performed; and 

using the simulation result as part of a data set that characterizes the actual process 
being performed by the semiconductor processing tool. 

2. The method of Claim 1, wherein said inputting process data comprises directly 
inputting the data relating to the actual process being performed by the semiconductor 
processing tool from at least one of a physical sensor and a metrology tool physically 
mounted on the semiconductor processing tool. 

3. The method of Claim 1, wherein said inputting process data comprises indirectly 
inputting the data relating to the actual process being performed by the semiconductor 
processing tool from at least one of a manual input device and a database. 
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4. The method of Claim 3, wherein said indirectly inputting comprises inputting data 
recorded from a process previously performed by the semiconductor processing tool. 

5. The method of Claim 3, wherein said indirectly inputting comprises inputting data 
set by a simulation operator. 

6. The method of Claim 1, wherein said inputting process data comprises inputting 
the data relating to a process performed by the semiconductor processing tool as virtual 
sensor data from a simulation module. 

7. The method of Claim 1, wherein said inputting process data comprises inputting 
data relating to at least one of the physical characteristics of the semiconductor processing 
tool and the semiconductor tool environment. 

8. The method of Claim 1, wherein said inputting data comprises inputting data 
relating to at least one of a characteristic and a result of a process performed by the 
semiconductor processing tool. 

9. The method of Claim 1, wherein said inputting a first principles physical model 
comprises inputting a spatially resolved model of the geometry of the semiconductor 
processing tool. 
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10. The method of Claim 1, wherein said inputting a first principles physical model 
comprises inputting fundamental equations necessary to perform first principles simulation to 
obtain a simulation result that can form part of a data set that characterizes the process 
performed by the semiconductor processing tool. 

1 1 . The method of Claim 1, wherein said performing first principles simulation 
comprises performing first principles simulation concurrently with the process performed by 
the semiconductor processing tool. 

12. The method of Claim 11, wherein said performing first principles simulation 
comprises performing first principles simulation to provide a simulation result that is a 
variation of a parameter tested by the concurrent process performed by the semiconductor 
processing tool. 

13. The method of Claim 11, wherein said performing first principles simulation 
comprises performing first principles simulation to provide a simulation result relating to a 
different parameter than a parameter tested by the concurrent process performed by the 
semiconductor processing tool. 

14. The method of Claim 1, further comprising performing first principles simulation 
not concurrently with the process performed by the semiconductor processing tool. 

15. The method of Claim 1, further comprising storing the data set in a library for 
subsequent use processes performed by the semiconductor processing tool. 
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16. The method of Claim 1, further comprising using a network of interconnected 
resources to perform at least one of the process steps recited in Claim 1. 

17. The method of Claim 16, further comprising using code parallelization among 
interconnected computational resources to share the computational load of the first principles 
simulation. 

18. The method of Claim 16, further comprising sharing simulation information 
among interconnected resources to facilitate a process performed by the semiconductor 
processing tool. 

19. The method of Claim 18, wherein said sharing simulation information comprises 
distributing simulation results among the interconnected resources to reduce redundant 
execution of substantially similar first principles simulations by different resources. 

20. The method of Claim 18, wherein said sharing simulation information comprises 
distributing model changes among the interconnected resources to reduce redundant 
refinements of first principles simulations by different resources. 

21. The method of Claim 18, further comprising using remote resources via a wide 
area network to facilitate the semiconductor process performed by the semiconductor 
processing tool. 


-32- 


U.S. Serial No. 10/673,501 

Appeal of Office Action dated February 27, 2008 

22. The method of Claim 21, wherein said using remote resources comprises using at 
least one of remote computational and storage resources via a wide area network to facilitate 


the semiconductor process performed by the semiconductor processing 


tool. 


23. A system comprising: 

a semiconductor processing tool configured to perform an actual process; 
an input device configured to input process data relating to the actual process being 
performed by the semiconductor processing tool; and 

a first principles simulation processor configured to: 

input a first principles physical model including a set of computer-encoded differential 
equations describing at least one of a basic physical or chemical attribute the semiconductor 
processing tool, and 

perform first principles simulation for the actual process being performed using the 
physical model to provide a first principles simulation result in accordance with the process 
data relating to the actual process being performed in order to simulate the actual process 
being performed, said first principles simulation result being produced in a time frame shorter 
in time than the actual process being performed, wherein the simulation result is used as part 
of a data set that characterizes the process performed by the semiconductor processing tool. 

24. The system of Claim 23, wherein said input device comprises at least one of a 
physical sensor and a metrology tool physically mounted on the semiconductor processing 
tool. 
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25. The system of Claim 23, wherein said input device comprises at least one of a 
manual input device and a database. 

26. The system of Claim 25, wherein said input device is configured to input data 
recorded from a process previously performed by the semiconductor processing tool. 

27. The system of Claim 25, wherein said input device is configured to input data set 
by a simulation operator. 

28. The system of Claim 23, wherein said input device is configured to input the data 
relating to a process performed by the semiconductor processing tool as virtual sensor data 
from a simulation module. 

29. The system of Claim 23, wherein said input device is configured to input data 
relating to at least one of the physical characteristics of the semiconductor processing tool and 
the semiconductor tool environment. 

30. The system of Claim 23, wherein said input device is configured to input data 
relating to at least one of a characteristic and a result of a process performed by the 
semiconductor processing tool. 

31. The system of Claim 23, wherein said processor is configured to input a first 
principles physical model comprising a spatially resolved model of the geometry of the 
semiconductor processing tool. 
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32. The system of Claim 23, wherein said processor is configured to input a first 
principles physical model comprising fundamental equations necessary to perform first 
principles simulation to obtain a simulation result that can form part of a data set that 
characterizes the process performed by the semiconductor processing tool. 

33. The system of Claim 23, wherein said processor is configured to perform said 
first principles simulation concurrently with the process performed by the semiconductor 
processing tool. 

34. The system of Claim 33, wherein said processor is configured to perform the first 
principles simulation to provide a simulation result that is a variation of a parameter tested by 
the concurrent process performed by the semiconductor processing tool. 

35. The system of Claim 33, wherein said processor is configured to perform the first 
principles simulation to provide a simulation result relating to a different parameter than a 
parameter tested by the concurrent process performed by the semiconductor processing tool. 

36. The system of Claim 23, wherein said processor is configured to perform said 
first principles simulation not concurrently with the process performed by the semiconductor 
processing tool. 
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37. The system of Claim 23, wherein said processor is further configured to store the 
data set in a library for subsequent use processes performed by the semiconductor processing 
tool. 

38. The system of Claim 23, further comprising a network of interconnected 
resources connected to said processor and configured to assist said processor in performing at 
least one of the inputting a first principles simulation model and performing a first principles 
simulation. 

39. The system of Claim 38, wherein said network of interconnected resources is 
configured to use code parallelization with said processor to share the computational load of 
the first principles simulation. 

40. The system of Claim 38, wherein said network of interconnected resources is 
configured to share simulation information with said processor to facilitate said process 
performed by the semiconductor processing tool. 

41 . The system of Claim 40, wherein said network of interconnected resources is 
configured to distribute simulation results to said processor to reduce redundant execution of 
substantially similar first principles simulations. 

42. The system of Claim 40, wherein said network of interconnected resources is 
configured to distribute model changes to said processor to reduce redundant refinements of 
first principles simulations. 
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43. The system of Claim 38, further comprising remote resources connected to said 
processor via a wide area network and configured to facilitate the semiconductor process 
performed by the semiconductor processing tool. 

44. The system of Claim 43, wherein said remote resources comprise at least one of a 
computational and a storage resource. 

48. At least one of non- volatile media and volatile media containing program 
instructions for execution on a processor, which when executed by the computer system, 
cause the processor to perform the steps of: 

inputting process data relating to an actual process being performed by the 
semiconductor processing tool; 

inputting a first principles physical model including a set of computer-encoded 
differential equations, the first principles physical model describing at least one of a basic 
physical or chemical attribute of the semiconductor processing tool; 

performing first principles simulation for the actual process being performed using the 
physical model to provide a first principles simulation result in accordance with the process 
data relating to the actual process being performed in order to simulate the actual process 
being performed, said first principles simulation result being produced in a time frame shorter 
in time than the actual process being performed; and 

using the simulation result as part of a data set that characterizes the actual process 
being performed by the semiconductor processing tool. 
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49. The method of Claim 1, wherein said performing a first principles simulation 
comprises: 

providing for the first principles simulation a reuse of known solutions as initial 
conditions for the first principles simulation. 

50. The system of Claim 23, wherein the first principles simulator is configured to 
provide for the first principles simulation a reuse of known solutions as initial conditions for 
the first principles simulation. 
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ADVANCED PROCESS CONTROL FOR 
SEMICONDUCTOR MANUFACTURING 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to process control systems 
including computer-based materials management. More 
precisely, the present invention relates to a feed forward 
process control system used in semiconductor fabrication 
based on material groupings. 

2. Description of the Related Art 

In the past, semiconductor manufacturing process control 
was largely achieved by ensuring that process parameters 
were set on a machine controller according to machine- 
dependent recipes. The basic philosophy of conventional 
semiconductor manufacturing process control is that if all 
settings that affect the process are set correctly, the machine 
will consistently produce a specified product. Using the 
conventional approach, manufacturing personnel act to 
relate machine settings to product characteristics. The 
approach has yet to be fully realized, however, due to a 
number of factors, including variability in equipment 
performance, variability in incoming materials such as 
wafers and chemicals, increasingly complex processes, and 
a lack of adequate models relating process settings to 
product characteristics. Success using the conventional pro- 
cess control approach becomes much less likely as the size 
of wafer features becomes smaller. 

Engineers have derived recipe settings based largely on 
experience, intuition, and, more recently, Response Surface 
Methodology (RSM) experiments. Initially, the recipes were 
manually downloaded to the equipment by operators/ 
technicians. Subsequently, Factory Control Systems incor- 
porating Equipment Integration (EI) functionality provided 
automated recipe management and download operations. 

Most recently, engineers have used Statistical Process 
Controls (SPC) concepts and methods for monitoring the 
performance of processes to verify that a process remains in 
a state of "statistical control." Initially, operators and tech- 
nicians performed SPC manually. Subsequently, all-manual 
charting was replaced with computerized factory control 
systems (FCS)-based SPC charts. In some cases automated 
Trouble Shooting Guides (TSGs) supplied automation to 
process control tasks. SPC is a fault detection methodology. 
TSGs perform rule-based classification and assist with prob- 
lem resolution. SPC helps distinguish between two types of 
process variation: common and special. SPC out-of-control 
signals are clues that are useful for identifying sources of 
special variation. Once a cause for special variation is 
determined, manufacturing can produce improvements in 
the process and product quality. As a fault detection and 
classification methodology, SPC relies upon an intimate 
understanding of the process and is largely manual and 
reactive. FIG. 1 is a schematic block diagram that shows a 
traditional SPC process. 

The conventional process control approaches have 
resulted in substantial progress. However, reactive process 
control techniques such as SPC do not achieve and sustain 
desired product yields and resource productivity, particu- 
larly in light of the size and speed specifications of future 
products. The semiconductor industry must continue to 
develop and deploy new process control methods. To 
address significant unresolved problems, an Advanced Pro- 
cess Control (APC) Framework is needed with the ability to 
provide: 

(1) Sensor-based automated fault detection to provide in 
real time the equipment or process conditions that 
result in a misprocessed wafer. 
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2 

(2) Classification of detected faults to determine the cause 
of a fault and expedite repair of a tool. 

(3) Model-based run-to-run process control using sensor 
inputs, process models, and process control strategies 

5 to ensure that the process remains optimal for every die 

on every wafer. 

(4) Model-based real-time process control using in situ 
inputs, process models, and process control strategies 
to correctly process control parameters during the pro- 

1° cess run, ensuring that product characteristics are 
achieved. 

Common Object Request Broker Architecture (CORBA) 
based technologies are used as a communication interface 
between clients and servers, often in highly complex sys- 

15 tems. Due to the complex nature of the systems, testing can 
be difficult. The system complexity arises because multiple 
components interact with one another over a network, which 
introduces problems. Many components operate both as a 
client and as a server since, in servicing a request, a 

20 component calls other remote services which, in turn, call 
other remote services. Testing of a client-server component 
is difficult since the component uses a driver to send requests 
and to send harnesses to emulate other components that 
interact with the client-server component. Also failures and 

25 performance problems may occur in any of multiple poten- 
tially remote components and therefore be difficult to isolate. 

The problems and complexities of these technologies 
including complexities arising from the integration of mul- 
tiple components, the verification of the correct operation of 

30 all of the multiple components individually and while 
interacting, and the analysis not only of correct operation but 
also of performance place a high demand on system test 
personnel. No longer can the least experienced developers 
perform the testing. More experienced architects are needed 

35 to specify and set up a testing infrastructure and perform the 
tests. 

What is needed is a strategy and technique that improves 
the management and prospects for success of the testing 
process. 

40 Present-day semiconductor manufacturing environments 
include the following characteristics that limit the ability of 
an environment to support the manufacture of complex, 
high-value products. First, stand-alone equipment control- 
lers have limited communications capability and limited 

45 provisions for external process control. Second, semicon- 
ductor manufacturing environments are limited by "static" 
(nonadaptive) process control approaches. Furthermore, 
present-day semiconductor manufacturing environments 
lack models to support the development and use of control 

50 algorithms. In addition the manufacturing environments are 
supplied by nonuniform, disparate, and incomplete sources 
of manufacturing data for driving process control algo- 
rithms. Closed, monolithic factory system architectures pre- 
vent integration of new capabilities, especially from mul- 

55 tiple suppliers. 

SUMMARY OF THE INVENTION 

In accordance with an aspect of the present invention, an 
Advanced Process Control (APC) framework, which is 

60 based on a Common Object Request Broker Architecture 
(CORBA) technology, includes a set of cooperating com- 
ponents to address the above-mentioned problems. Compo- 
nents appearing as CORBA objects are designed to attain the 
facility and simplicity of plug-and-play operation. The APC 

65 framework integrates with a legacy Manufacturing Execu- 
tion System (MES) and enables run -to -run control for mul- 
tiple equipment in semiconductor manufacturing. 
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The APC Framework performs automatic process control 
operations through the design and development of a soft- 
ware framework that integrates factory, process, and equip- 
ment control systems. The APC Framework benefits 
semiconductor-manufacturing manufacturing, factories, or 
"fabs," throughout the development of the APC Framework 
by using an iterative development approach. The APC 
Framework is designed to integrate seamlessly with 
commercially-available APC tools 

The APC Framework specifies components and a com- 
ponent structure that enable multiple vendors to build and 
sell framework-compatible products using an open architec- 
ture that accommodates plug-and-play components. The 
APC Framework advantageously increases product yield 
distributions and equipment utilization, and lowers defect 
densities. 

Performance specifications of the APC Framework are 
driven by the requirement for reduced feature size on 
semiconductor wafers. The APC Framework is integrated 
with manufacturing tools and a File Control System (FCS). 
Components of APC Framework are to be commercially or 
internally supported at some time in the future. APC process 
control models/algorithms are developed internally. The 
APC Framework augments existing equipment controllers. 

In accordance with an embodiment of the present 
invention, a computer program product includes a computer 
usable medium having computable readable code embodied 
therein including a process control software system control- 
ling a process having a plurality of devices communicating 
in a network, the devices including a metrology machine, a 
processing machine, and a controller. The process control 
software system includes a metrology machine plan routine 
controlling operations of the metrology machine. The 
metrology machine plan routine generates a human readable 
text describing activities to be exercised by the metrology 
machine and data to be collected and analyzed by the 
metrology machine. The process control software system 
also includes a processing machine plan routine controlling 
operations of the processing machine. The processing 
machine plan routine generates a human readable text 
describing activities to be exercised by the processing 
machine and data to be collected and analyzed by the 
processing machine. The process control software system 
further includes a strategy routine controlling operations of 
the controller. The strategy routine coordinates activities of 
the metrology machine plan and the processing machine 
plan that span multiple processing steps of the process. 

The illustrative test system and operating method have 
many advantages. Advantageously, the Object Management 
Group (OMG) Interface Definition Library (IDL) supports 
the definition of interfaces. The interfaces are stable so that 
clients and servers are developed independently. Indepen- 
dent development is best accomplished through usage of 
OMG IDL in the definition of exceptions, attributes, and 
sequences. 

The OMG IDL-to-C++ advantageously supports standard 
and alternative mappings for modules. The OMG IDL-to- 
C++ supports a standard mapping for compilers that support 
name spaces and nested classes and an alternative mapping 
for other compilers. The alternative mappings disadvanta- 
geous^ may result in portability problems. Furthermore, 
OMG IDL advantageously supports a number of basic and 
constructed data types that are mapped via an IDL compiler 
into data structures suitable for a particular programming 
language. For example, in the C++ language data types are 
limited to fairly primitive types for sequences and strings. 
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Other data structures are used that offer more functionality 
and do not impact performance. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 The present invention may be better understood, and its 
numerous objects, features, and advantages made apparent 
to those skilled in the art by referencing the accompanying 
drawings. 

FIG. 1, labeled PRIOR ART, is a schematic block diagram 
io showing a traditional SPC process. 

FIG. 2 is a schematic block diagram showing material 
flow of a semiconductor manufacturing process from a 
process engineer perspective. 

FIG. 3 is a schematic block diagram showing material 
15 flow of a pre-process measurement step of a semiconductor 
manufacturing process from a process engineer perspective. 

FIG. 4 is a schematic block diagram showing material 
flow of a processing step of a semiconductor manufacturing 
20 process from a process engineer perspective. 

FIG. 5 is a schematic block diagram showing material 
flow of a post-process measurement step of a semiconductor 
manufacturing process from a process engineer perspective. 
FIG. 6 is a schematic block diagram showing APC 
25 Framework components that support APC scenarios. 

FIG. 7 is a schematic block diagram illustrating the 
architecture of a typical Advanced Process Control (APC) 
component. 

FIG. 8A is a schematic block diagram illustrating a system 
30 architect perspective in a plan startup phase an Advanced 
Process Control (APC) system for performing an Advanced 
Process Control (APC) strategy. 

FIG. 8B is a schematic block diagram illustrating a system 
architect perspective of the APC system using Plug-In 
35 Execution. 

FIG. 8C is a schematic block diagram illustrating a system 
architect perspective of the APC system during a Processing 
Measurement Step. 
40 FIG. 8D is a schematic block diagram illustrating a 
system architect perspective of the APC system during a 
Post-Processing Measurement Step. 

FIG. 9 is a schematic block diagram that illustrates an 
embodiment of an AddOnSensor Interface (SI) component. 
45 FIG. 10 is a schematic state transition diagram depicting 
a Data Collector. 

FIG. 11 is a class diagram showing an embodiment of the 
AddOnSensor class. 

FIG. 12 is a class diagram showing an embodiment of the 
50 communication layer Data Acquisition (DAQ) class. 

FIG. 13 is an object collaboration diagram showing an 
embodiment of the AddOnSensor Initialization class. 

FIG. 14 is a collaboration diagram showing an embodi- 
ment of the communication layer (DAQ) Initialization. 
55 FIG. 15 is a collaboration diagram showing an embodi- 
ment of the communication layer (DAQ) Clean Up. 

FIG. 16 is a schematic block diagram showing a process 
for performing a setup of data collection in the APC. 
60 FIG. 17 is a schematic block diagram showing a process 
for performing enabling of data collection in the APC. 

FIG. 18 is a schematic block diagram showing a process 
for performing disabling of data collection in the APC. 

FIG. 19 is a schematic block diagram showing a process 
65 for starting data collection in the APC. 

FIG. 20 is a schematic block diagram showing a process 
for stopping data collection in the APC. 
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FIG. 21 is a schematic block diagram showing a process 
for performing data collection buffering in the APC 

FIG. 22 is a schematic block diagram showing a process 
for performing data collection triggering in the APC. 

FIG. 23 is a schematic block diagram showing a process 5 
for performing an unsetup of data collection in the APC. 

FIG. 24 is a schematic block diagram illustrates an UML 
collaboration diagram. 

The use of the same reference symbols in different draw- 10 
ings indicates similar or identical items. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT^) 

The APC Framework includes specification of various 15 
project requirements, objectives, and implementation crite- 
ria. The APC Framework further defines a list of high-level 
system functions, a set of system-level use cases, and a data 
dictionary defining a glossary of terms and concept defini- 
tions. The APC Framework also includes specification of a 20 
system-level architecture design and identification of sub- 
systems. In the illustrative embodiment, the APC Frame- 
work utilizes an Object Modeling Technique (OMT) meth- 
odology to set forth the design approach and artifacts 
generated. 25 

Once the APC Framework subsystems are identified, the 
APC Framework proceeds through an iterative process of 
analysis, design, implementation, deployment, and commer- 
cialization following a final iteration. In each phase, the APC 
components are incrementally enhanced in functionality. For 30 
each successive iteration, emphasis on component function- 
ality is decreased and replaced by emphasis on applying the 
framework to solving APC problems of increasing complex- 
ity. At the end of an iteration, a comprehensive integration 
test is performed to ensure that all components work accord- 35 
ing to the IDL specifications and a performance evaluation 
is completed before the components are deployed in a 
fabrication facility. 

The iterative process allows rapid evaluation and valida- 4Q 
tion of the APC Framework concepts. Each analysis phase 
at different iterations allows revaluation of design philoso- 
phy and approach, tools, and methodologies, before further 
enhancing the system. 

In the illustrative embodiment, the APC Framework is 45 
implemented in framework components using C++ on Win- 
dows NT-based platforms. Some user interface clients are 
implemented in Java. 

Referring to FIG. 2, a schematic block diagram shows 
material flow of a semiconductor manufacturing process 50 
from a process engineer perspective. The diagram shows 
how the APC Framework 200 supports a typical run-to-run 
control scenario. The diagram is presented from the per- 
spective of the framework's primary user, the Process Con- 
trol Engineer. Concepts including "plan" and "strategy" 55 
clarify ideas and crystallize concepts. A "plan" is a human 
readable text describing activities that are exercised and data 
that is collected and analyzed. Plans orchestrate all APC 
activities. A strategy is similar to a higher level plan, but 
coordinates activities that span multiple processing steps. 60 
For example, a strategy specifies the order of running of 
plans. 

The illustrative APC Framework 200 includes a process 
model 202 that receives feed-forward and feed-back data 
and calculates a processing parameter. The illustrative por- 65 
tion of the APC Framework 200 includes two measurement 
devices, in particular a pre-process metrology machine 204 
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and a post-processing metrology machine 206. The pre- 
process metrology machine 204 performs a measurement on 
a material prior to processing in a processing machine 208 
and sends the measurement, as feed-forward data, to the 
process model 202. The processing machine 208 sends 
processed material to the post-processing metrology 
machine 206 to measure post-process data which is sent to 
the process model 202 as feedback data. 

Plans in the APC Framework 200 include a pre-process 
metrology plan #1 210, a process material plan #2 212, and 
a post-process metrology plan #3 214 which are defined 
within the APC strategy #1 216. 

Referring to FIG. 3, a schematic block diagram shows 
material flow of a pre-process measurement step 300 of a 
semiconductor manufacturing process from a process engi- 
neer perspective. An APC plan 302 sends a message to a 
machine 304 to measure a material. The machine 304 sends 
measured measurement data back to the plan 302. The plan 
302 stores the measurement data in a data store 306 of a 
database 308 for usage at a processing step. The plan also 
sends the measurements to a data history store 310 of a 
historical database 312. 

Referring to FIG. 4, a schematic block diagram shows 
material flow of a processing step 400 of a semiconductor 
manufacturing process from a process engineer perspective. 
An APC plan 402 retrieves a process model from the data 
store 306, then executes a parameter calculation algorithm 
404. The APC plan 402 gives the calculated parameters to a 
machine 406 and directs the machine 406 to execute the 
process. The machine 406 issues a signal to the APC plan 
402 when the process execution is complete. The APC plan 
402 sends the calculated parameters to the data history store 
310 of the historical database 312. 

Referring to FIG. 5, a schematic block diagram shows 
material flow of a post-process measurement step 500 of a 
semiconductor manufacturing process from a process engi- 
neer perspective. An APC plan 502 sends a message to a 
machine 504 instructing the machine 504 to measure a 
post-processed material. The machine 504 sends measure- 
ment data to the APC plan 502. The APC plan 502 retrieves 
an old process model from the data store 306. The APC plan 
502 executes a model update algorithm 506. The APC plan 
502 stores an updated model in the data store 306 for usage 
in the processing step 400. The APC plan 502 sends new 
model data to the data history store 310 of the historical 
database 312. 

Referring to FIG. 6, a schematic block diagram shows 
APC Framework components that support APC scenarios. 
TABLE I summarizes the APC components and the primary 
functionality of the components. 


Component Description 

Execution/Co ntro 1/ 

Monitoring 

Components 

Plan Execution Provides for execution of APC strategies, plans, and 

associated process control scripts, interacting with 
other components as dictated by the contents of the 
scripts to provide desired process control functional- 
ity. 

Fault Detection Provides factory operations and engineering 

Monitoring personnel with a "window" into the current and 

past state of processing equipment, including 
processing activity, alarms, and faults. 
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-continued 


-continued 


Component 


Description 


Component 


Description 


Capability Providers 
Machine Interface 


5 Trader 


Sensor Interface 


Operator Interface 


Application 
Interface 

Document 

Management 

Components 

Document 
Management 


Data Collection 
Plan Management 


Plug-in 
Management 


Plan Management 


Sign-Off 
Management 

Data Storage 
Components 

Data Store 

Data History 

Administrative 

Support 

Components 

Component 
Management 

System 

Management 

Logger 

Registry 


CORBA Services 
Components 

Events 


Provides an interface between MES equipment 
interfaces (Els) and the APC representation of a fab 
tool. Primarily translates between El-specific 
communications and APC CORBA. 
Provides the appropriate interface environment to 
execute sensor data acquisition Plug-in applications 
(e.g., Lab view VI). 

Facilitates communication between a wafer fab 
technician (WFT) and the APC system via a 
graphical user interface (GUI). 
Provides the appropriate interface environment to 
execute control Plug-in applications such as Matlab 
and Mathematica. 


Provides base implementation of documents under 
version control for extended implementation by 
other Document Management components (Data 
Collection Plan Management, Plug-in Management, 
and Plan Management). 

Extends Document Management for configuration 
and management of data collection plans, associated 
duration plans, sampling plans, and reporting plans. 
At run time, provides the appropriate plan to Plan 
Execution Management component. 
Extends Document Management for definition, 
importing, and management of process control 
Plug-in applications that are developed with 
tools external to the APC system, such as Matlab, 
Mathematica, MatrixX, etc. 

Extends Document Management for definition, con- 
figuration, and management of APC strategies, 
plans, and scripts, and defines when they are 
to be used. At run time, tracks strategy execution 
progress. 

Provides change management, sign-on, 

and effectivity administration to support other 

Document Management components. 


Stores and retrieves control models and s 
data required for process control. 
Provides for historical repository and archival of 
APC data for use in off-line analysis. 


Provides administrative, configuration, event, and 
state services for all servers developed for the APC 
framework. 

Defines, groups, installs, and manages the 

components in the APC system. 

Provides centralized services for capturing activity 

and trace information for diagnostic and monitoring 

purposes. 

Maintains a centralized repository of component 
configuration information, including setup values, 
system environment settings, and 
lists of dependent objects and event channels. 


Provides basic support for asynchronous events 
(decoupled event suppliers and consumers), event 
"fan- in," notification "fan-out," and-through 
appropriate event channel implementations-reliable 
event delivery. 


15 


20 


35 


Supports a service-based lookup for components to 
find other components which provide needed servic- 
es. Component lookups can be constrained to limit 
the components to be retrieved, based on 
component-specific or instance-specific properties. 


Referring to FIG. 7, a schematic block diagram illustrates 
the system architecture of a typical Advanced Process Con- 
trol (APC) component 700 and shows functional intercon- 
nections and architecture design details common to a plu- 
rality of components in the APC framework. The 
architecture diagrams show scenarios from a system archi- 
tecture perspective. The architecture diagrams highlight how 
interactions between APC components achieve the desirable 
outcome for the Process Engineer. Boxes with rounded 
corners represent objects, single-headed arrows are method 
calls, and double-headed arrows are events. 

APC components 700 have characteristics and behaviors 
that are defined by the APC Framework to set a base level 
of functionality of all components. A plurality of APC 
25 components 700 cooperate to perform APC applications 
such as run-to-run control and have specified common 
behaviors including behaviors that support installation and 
system administration. 

The APC component architecture defines a single set of 
30 services available to all clients. A system management client 
702 specifically exploits the services and interacts with 
various components to install initial versions and new 
releases of the components and to control the logging levels 
of the components. An Object Management Group (OMG) 
Interface Definition Library (IDL) interface is defined to 
support a base level of component functionality. All com- 
ponents inherit the common OMG IDL interface which sets 
the fundamental functionality of the component. Function- 
ality of a particular component is further defined to supply 
an individual domain-specific functionality. The APC frame- 
work supplies a single implementation of the common OMG 
IDL interface so that domain -specific components inherit the 
OMG IDL behavior without concern about implementation. 
The common basic shared-implementation of the interface 
advantageously increases robustness of the system. 
Although a single implementation of the interface is sup- 
plied for usage of the components, individual components 
may have a unique implementation of the interface, if 
desired, so long as returned object fully supports the base 
OMG IDL interface. 

The system management's client 702 binds to a selected 
component 700 at run-time and the component returns an 
object that supports the common OMG IDL interface. As 
long as the base interface supports the OMG IDL 
55 specifications, the system management client 702 safely 
guides a returned object to the interface. The system man- 
agement client 702 can then apply operations defined for the 
interface to install a component, upgrade a component, and 
control the logging levels. The common base interface 
60 advantageously simplifies the implementation of the system 
management client 702 across a wide range of components. 

The system management client 702 is the component that 
calls a bind function to obtain object references. Other 
components, except a trader component, import bindings 
65 from a trading service (not shown). The ACP architecture 
localizes uses of the bind operation because, although sup- 
plied by a number of vendors, bind is not a CORBA- 


45 


50 
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compliant way to obtain the object references. In the case of 
a system manager server 704, bind is used to break a cyclic 
dependency and bootstrap the system. The system manager 
702 uses object references to install the components, but 
does not obtain the object references from the trading 
service until the components are installed. By using bind, the 
system manager server 704 obtains and exports the object 
references to the trader. Once the components are installed, 
all components can use the trader to import the object 
references. 

The trader is an initial reference that is retrieved in a 
non-standard fashion using bind. A CORBA 706 initializa- 
tion service supplies a standard technique to resolve initial 
references using the Object Request Broker(ORB), but only 
uses a conforming implementation to support a naming and 
interface repository. In the illustrative embodiment, the 
trader is not a mandatory reference that is resolved using the 
ORB so the ORB is used to resolve an initial reference to the 
naming service and the naming service is used to find the 
trader. In other embodiments, the trader service is obtained 
via a call to bind. The call to the bind function is localized 
inside a single procedure. After acquiring the trader, other 
references are resolved either through the trader or by 
applying operations to objects that are retrieved from the 
trader. In further additional embodiments, the trader is a 
mandatory reference. 

A profile contains component-specific information that 
can be specified after the component 700 has been compiled. 
The profile is loaded at run time by the component 700 when 
the component is started. The system manager 702 creates 
the profile as part of the installation of a component. The 
profile is stored in a registry 708 for later retrieval. At run 
time, the name of the APC component 700 is passed on a 
command line (not shown). The APC component 700 uses 
the component name to access the profile allocated to the 
component in the registry 708. The profile includes three 
sequences: a first sequence containing internal variables, a 
second sequence containing environment variables, and a 
third sequence containing the binding variables. 

The profile specifies internal variables for component- 
specific settings. For example, a component may use a first 
database during testing and a second database during pro- 
duction. In another example, a component may capture 
timing and tracing information during testing, but not during 
deployment. Internal settings in a profile are represented as 
a sequence of name-value pairs where the value is a string. 

The profile has environment variable settings that are 
used, for example, to support operation of components that 
integrate legacy systems. For example, a CORBA compo- 
nent that acts as an Oracle client 710 has a LIBPATH set to 
dynamically load Oracle client libraries correctly. Failure to 
correctly set the LIBPATH results in a runtime exception. 
The environment variables inside a profile are represented as 
a sequence of name-value pairs where the value is a string. 

The profile has binding variables that specify a selection 
criterion used at runtime to import service providers to the 
APC component 700. In multi-tier architectures, compo- 
nents that use the services of other components are preva- 
lent. For a robust system, APC components 700 do not 
statically bind to these service providers. Instead, the APC 
components 700 dynamically acquire service providers at 
runtime for greater flexibility and robustness. If a requested 
service provider is inoperable for an extended time, the 
service provider is selectively replaced by changing the 
binding information in the profile. A binding variable is also 
used to locate either a logging service 712 that the APC 
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component 700 uses to send timing and tracing information, 
or the event channels 714 the APC component 700 uses to 
send and receive events. Binding variables are stored in the 
profile as a sequence of name-value pairs where the value is 
5 a structure defined in OMG IDL as: 

struct BindingValuej string type; string constraint; bool- 
ean mandatory _presence; }; 
struct Binding Variable { string name; Binding Value value; 
}* 

10 typedef sequence<BindingVariable >BindingVari- 
ableSeq; 

The mandatory presence field is used because some 
bindings are optional. For example, components can be 
coded to operate with or without a particular binding. 

15 One example of the usage optional bindings arises for a 
APC component 700 that connot connect to the logging 
service 712 after successfully processing a long-duration 
operation. Although the operation is successful, the log is 
not found, possibly because the log is contained on a 
machine that is temporarily inoperable. Rather than 

20 unwisely aborting the operation merely because the logging 
service is not found, a better solution is to specify an 
alternative log. For example, the logging utility may be 
implemented using a smart proxy so that a failure to connect 
to the logging service is addressed by logging to a local file 

25 or logging to a console based on an internal setting. A 
logging utility using a technique such as a smart proxy 
allows the binding handle to the logging service to become 
optional so that the APC component 700 can operate with or 
without the logging service operative. The binding value for 

30 the optional logging service specifies a "false" designation 
for the mandatory presence field. 

In a distributed system, the location of failure for a thread 
of control is difficult to determine. A list of potential failure 
locations is reduced by running components on a single 

35 machine. However, the logging of some tracing information, 
including request, reply, and exception events, is valuable. 
The logging of tracing information advantageously allows 
the components to leave a trail so the tester can find and 
diagnose problems. 

40 Performance bottlenecks are isolated in a system by 
determining round-trip timing information such as the time 
to issue a request and receive a reply in response to the 
request. Once round trip times are determined, system devel- 
opers focus on improving the performance of request and 

45 response paths with a longest time duration so that the 
developer is best able to discover ways to optimize the 
request. A developer may find a request that obtains several 
object references, opens and closes a database, and creates 
a process. In such a request, performance is improved by 

50 caching references, opening the database once, and dynami- 
cally linking new functionality. The requests that extend the 
longest time are not always optimized, but the tuning system 
performance is generally improved. 

In a typical system, no tools for tracing and timing 

55 intercomponent interactions exist so that support for captur- 
ing information is to be incorporated into the system. The 
system is to be able to disable the capturing of information 
in a manner that does not impact runtime performance when 
deployed. An advantageous technique for capturing infor- 

60 mation is to use filters or interceptors that are called by the 
ORB at key points during the servicing of a request. Such 
key points include the time of sending a request, the time of 
receiving a request, and the time of sending a reply. The 
filters are implemented to log the tracing and timing infor- 

65 mation to a central server. The filters achieve correct logging 
of the information without the application programmers 
having to make explicit calls. 
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The System Management Component 702 is used to 
perform system management and configuration on APC 
components. An entire APC system uses a single System 
Management component 702. The System Manager 702 
does not have to be present for APC components to continue 5 
running. The System Management Component 702 has two 
subcomponents: the System Manager Server 704 and the 
System Manager Graphical User Interface (GUI) 703. The 
System Manager Server 704 communicates with the APC 
components directly, whereas the System Manager GUI 703 10 
communicates only with the System Manager Server 704 via 
CORBA. The System Manager GUI 703 can be replaced by 
any available GUI implementations (e.g., Java, Virtual 
Basic, or PowerBuilder) that comply with CORBA, while 
the business rules and database access are left strictly to the 15 
System Manager Server 704. 

A Machine Interface Component 714 is an interface to a 
single piece of semiconductor processing or metrology 
equipment 716. Through the Machine Interface 714, the 
APC system delivers processing parameters, controls equip- 20 
ment operation, collects equipment status information, and 
receives collected data. The Machine Interface 714 bridges 
the gap between an existing Equipment Interface (EI) 716 
and the APC framework. The Machine Interface 714 trans- 
lates specific selected messages and events on a CORBA bus 25 
718 to an Isis bus 720, and back to the CORBA bus 718. The 
Isis bus 720 is used by the Equipment Interface 716. The 
Machine Interface 714 also facilitates the startup and shut- 
down operations that are initiated by the System Manage- 
ment Component 702. The Machine Interface 714 makes 30 
publicly available a CORBA event channel. All CORBA 
events generated by the existing Equipment Interface (EI) 
716 are made available on the CORBA bus 718. In the 
illustrative embodiment, every instance of a Machine Inter- 
face 714 is associated with one and only one (CORBA) Plan 35 
Execution Manager and one and only one Equipment Inter- 
face 716. 

An Operator Interface (OI) 722 component facilitates 
communication between an operator 724, for example a 
Wafer Fab Technician, and the APC system. Through a 40 
CORBA interface 726, the component allows users to dis- 
play a variety of pop-up dialogs simultaneously on any 
number of displays 728. The Operator Interface 722 also 
supports for the startup/shutdown and logging features used 
by the System Management Component 702. 45 

The OI component 722 has a title base attribute that 
specifies a string common to all pop-ups. Operations that 
display pop-ups add either static or user-defined suffixes to 
the title. For example, if the attribute is set to "CVD09," a 


notify pop-up that displays a message and "OK" button, a 
query pop-up that displays a message and "Yes" and "No" 
buttons, and a prompt pop-up that displays a message, 
response string, and "OK" button. 

An announcement operation is defined as a one-way 
message that displays a simple pop -up with message and 
"OK" button. Unlike the other pop-ups, the operation does 
not wait for user dismissal. This operation does not return 
any information. 

After dismissal, all pop-up operations except the 
announcement pop-up return the button label that was 
pressed and the particular display that dismissed the pop-up. 
If the pop-up displayed a response string, the operator's 
response is returned. If the pop-up had a time out, a boolean 
is returned indicating if the pop -up was dismissed due to 
time out. Dismissing a pop-up on one display causes the 
pop-up to be removed from all other displays on which it 
was shown. 

An Application Interface (AI) component 730 supplies an 
interface to an external application 732, usually an applica- 
tion that runs a control algorithm. The AI 730 executes 
Plug-ins inside an application associated with the AI com- 
ponent 730. The Plug-in object contains user-supplied code 
and non-APC data such as algorithmic constants and setup 
parameters for the application. The Plug-in executes in the 
manner of a function call. The Plug- in receives Input param- 
eters. When the Plug-in has finished receiving the Input 
parameters, the Plug-in returns and supplies Output param- 
eters. The AI component 730 translates data transferred 
between the Plug-in and APC. 

A Data Store Component 734 is used to store APC data 
created during StrategyRuns. The Data Store Component 
734 stores two types of information including permanent 
data that stores values used by the APC system across runs 
and Temporary data that APC scripts use to store any general 
values for a particular strategy run. Examples of permanent 
data include default model parameter and recipe adjustment 
values. The Data Store Component 734 provides persistent 
storage for the APC Plan Execution component. The Data 
Store Component 734 interacts with the Plan Executor 808, 
which is described in the discussion of FIG. 8A, as an only 
client. 

The APC system also includes a Data History Component 
736. When the APC is running, a data storage location is 
used to record event occurrences. When a run starts, a recipe 
changes, run data is collected, or a model parameter value 
changes, all events are logged so that data collected is later 
retrieved and analyzed. The APC framework presumes that 
the history data analysis package is outside the system, and 
thus a relational database is chosen to store historical 


call to the notify operation would display a pop-up with 50 records. The data history is stored in a relational-friendly 

way for retrieval efficiency and usability, as opposed to a 
more object-oriented view. 

The APC component 700 is a fundamental building block 
of the APC Framework which is distributed, object-oriented, 
55 and based on the standards of CORBA CORBA services, 
and CORBA facilities. Individual APC components 700 are 
defined to achieve interoperability so that components oper- 
ate together, substitutability so that components can be 
replaced or upgraded, extensibility so that component func- 
60 tionality can be extended and specialized, scalability so that 
the APC Framework is used on a large or small scale, and 
migratability so that the APC Framework evolves. 

The APC Framework is designed to integrate with legacy 
systems such as existing monolithic shop floor control 
65 systems. Furthermore, the APC Framework integrates with 
existing process modeling tools such as Matlab and Matrix- 
X. 


'Too Notification" as the title, whereas a call to the query 
operation would display a pop-up with "CVD09 Query" as 
the title. 

The OI component 722 also has a display list that specifies 
the displays in which a pop-up could appear. As a parameter 
to a pop-up operation, the user may specify that a pop-up 
appear in only a subset of the display list. Additional 
operations are defined that allow users to add and remove 
displays from the display list. 

The OI component 722 includes a flexible mechanism for 
displaying information to the operator via pop-ups. A 
generic pop-up operation allows users to specify the title 
suffix, the text message, a list of button labels, an optional 
response string, a priority level, an optional time out, and a 
list of displays. 

In addition to the generic pop-up, several operations are 
defined that display specialized pop-ups. These include a 
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The system functional requirements are derived primarily 
to support two typical scenarios including run-to-run 
control, and fault detection and classification. Run-to-run 
control is a model-based process control that usually 
involves more than one piece of processing equipment. In a 
typical usage scenario, the results of material processing at 
one piece of equipment are passed, or "fed-forward" to a 
subsequent manufacturing step, and used to influence the 
future processing of the same material. In the APC 
Framework, run-to-run control is performed according to 
mathematical process models, and a single application 
accommodates multiple feed-forward and feedback loops. 

Fault detection and classification is model-based detec- 
tion and classification of process equipment problems. Data 
is collected from a piece of processing equipment and 
analyzed using an idealized mathematical process model. 
Results of the analysis are used to detect the occurrence or 
likelihood of occurrence of an equipment fault, and to 
determine the type of the fault. 

Both run-to-run control and fault detection and classifi- 
cation are supported using a single set of APC Framework 
components. Alternatively, the support of different types of 
APC functionality and adaptation to the specifications of a 
particular APC installation require considerable flexibility 
from the APC Framework design. Flexibility is achieved by 
assembling the APC components in different combinations 
to conform to application specifications. 

Referring to FIG. 8A in conjunction with FIG. 7, a 
schematic block diagram illustrates a system architect per- 
spective in a plan startup phase an Advanced Process 
Control (APC) system for performing an Advanced Process 
Control (APC) strategy. A Plan Execution Component 802 
services a single semiconductor processing machine (the 
"machine") and metrology devices associated to the 
machine. The Plan Execution Component 802 retrieves a 
plan (the "plan") and scripts associated to the plan from a 
Plan Manager 804 upon receipt of a "run_APC" command 
from a Manufacturing Execution System (MES) 801. The 
Plan Execution Component 802 then obtains a list of capa- 
bilities for suitably executing the plan from a trader 805, 
sequences the execution of the plan, and generates a report 
of plan execution. The report of plan execution specifies 
whether the plan successfully completed and reports errors, 
if any, resulting from plan execution. 

A Plan Execution Component 802 contains one Plan 
Execution Manager (PEM) 806 that is responsible for the 
overall management of all plans executed on the assigned 
semiconductor processing machine and also responsible for 
metrology devices associated with the machine. The PEM 
806 creates a Plan Executor (PE) 808 to execute a running 
plan 803. A PE 808 is responsible for a single plan 803. The 
PE 808 exists for the life span of the plan 803 and is 
destroyed after reporting plan 803 completion. A PE 808 
executes a "main script" 807 and may execute one or more 
"event scripts" that are triggered by events. Functions per- 
formed by a PE 808 include: (1) Creating a script executor 
to execute the main script; (2) Allowing a channel for events 
to be received from different components; (3) Activating 
event script executors, for example, if triggered by an event; 
(4) Maintaining a sharable address space for communica- 
tions between the main script and the event scripts; and (5) 
Supplying stubs to map calls from the scripts to external 
objects. 

A Plan Executor (PE) 808 under normal working condi- 
tions generally interfaces with the PEM 806, a Data Store 
Component 810 (see FIG. 8C), the Plan Manager 804, a 
Machine Interface Component 812 (see FIG. 8B), an 
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AddOnSensor Interface Component (not shown), a Data 
History Component 816 (FIGS. 8C and 8D), a Plugln 
Manager 822 (see FIG. 8B), and various Application Inter- 
face Components (not shown). The Plan Executor (PE) 808 

5 controls a plan startup operation determined by several 
control parameters including a processing context, runtime 
parameters, development parameters, 

The Plan Execution Manager (PEM) 806 manages inter- 
face calls to the APC Plan Execution Component (PEC) 802. 

in The interface calls include: 


1. executors(); //returns a list of current executors 

2. executors__running_planO; //returns a list of Plan Executors (defined 
15 below) running the specified plan 

3. run_apcQ; //retrieves and executes a plan 


The PEM 806 also supplies an interface on behalf of each 
PE 808 associated to the PEM 806. The interface calls 
20 include: 


1. plan(); // returns the current plan and context run by the executor. 
This is unique since a PE runs only one plan. 
25 2. stopO; // stops execution of the current plan at the next plan step 

3. suspendO; // stops execution of the current plan at the next plan step 

4. abort(); // stops execution of the current plan at the next plan step 

5. resumeQ; // resumes execution of the current plan at the next plan step 


30 The illustrative interface calls may be defined differently 
for other applications. The depicted interface calls are 
selected to reflect typical functions and operations per- 
formed by a typical PE 808 and PEM 806. In other 
embodiments, a PEM 806 may start multiple plans concur- 
rently using multiple PEs 808. 

The Plan Manager (PM) component 804 manages APC 
Strategies, Plans, and Scripts artifacts. The Plan Manager 
804 creates and configures Strategies and Plans. Scripts are 
assumed to be created by a separate Script Creation Tool. 
During runtime, the Plan Manager 804 provides the APC 
System access to the configured Strategies, Plans, and 
Scripts. 

Plans are sequentially configured in a Strategy. Once a 
Strategy is selected, an executing instance, the StrategyRun, 
is created. StrategyRun spans the lifetime of executing all 
plans in a Strategy. Strategies and StrategyRuns are selected 
by matching them with an MES Context. This context is 
matched to the appropriate Strategy using a Context- 
Specification and a set of Context-Matching Rules. A 
Context-Specification is a list of specifications that match 
specified parameters from the context. Thus the complete 
configurations of a Strategy include a context specification. 
During runtime, the specification is used to retrieve the 
appropriate Strategy and execute the associated current Plan 
of the Strategy. Once the Plan and the Scripts contained in 
the plan have executed, the Plan Manager 804 prepares the 
StrategyRun to process the next plan. 

Referring to FIG. 8B, a schematic block diagram illus- 
trates a system architect perspective of the APC system 
using Plug-In Execution. A Plug-in Management Compo- 
nent 822 includes three main objects, a Manager 824, a 
Plug-in 826, and a Blob 828. The Manager 824 checks 
Plug-ins 826 and Blobs 828 out of the persistent storage and 
manages the memory used for Plug-ins 826 and Blobs 828. 
The Plug-in 826 is an object that contains user-defined 
executable code, any nonvolatile data used to run the code 
such as constants and initial values, and source code for the 
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executable program. A Blob 828 is an envelope for data in 
any number of formats and is used to eliminate the need for 
APC to know the format of the user-defined code or data. A 
Plug-in 826 typically contains references to several Blobs 
828. 5 

The executable code contained in a Plug-in 826 within a 
Blob 828 executes in one of many possible environments 
including Matlab or Xmath environments. The data in other 
Blobs 828 referenced by a particular Plug-in 826 is format- 
ted suitably for the appropriate environment. A limitation on 10 
the number of execution environments available from APC 
is undesirable so that the Blob 828, as a generic envelope, is 
defined to shield the APC from the specific code and data 
formats of each execution environment. An Application 
object 825 configures the Blob 828 for usage in the appro- 15 
priate execution environment. The format of the Blob 828 
contents are immaterial to the Manager 824 and the Plug-in 
826. 

The Manager 824 calls the constructors and destructors of 
the Plug-in 826 and Blob 828, and passes references to 20 
Plug-ins 826, when requested. 

Referring to FIG. 8C, a schematic block diagram illus- 
trates a system architect perspective of the APC system 
during a Processing Measurement Step. Following startup, 
the Plan Executor (PE) 808 notifies the Plan Manager 804 25 
that the plan is started and retrieves permanent stored data 
tags from the data store manager 809 of the Data Store 
Component 810. The plan executes a plug-in to calculate 
new processing parameter values. The PE 808 sends APC 
data parameters and a start machine signal to the Machine 30 
Interface Component 812. The Machine Interface Compo- 
nent 812 begins operating and sends a "machine started" 
signal to the PE 808. When the operation of the Machine 
Interface Component 812 is complete, the Machine Interface 
Component 812 sends a "machine finished" notification to 35 
the PE 808. The PE 808 generates and sends a product run 
record 817 to the data history manager 815 of the Data 
History Component 816 and sends run data to the run record 
817 of the Data History Component 816. The PE 808 sends 
a plan completed signal to the Plan Manager 804. The PE 40 
808 then terminates while the Plan Manager 804 registers 
that the second plan for the strategy run is complete. 

Referring to FIG. 8D, a schematic block diagram illus- 
trates a system architect perspective of the APC system 
during a Post-Processing Measurement Step. The Plan 45 
Executor (PE) 808 performs a plan startup. Following 
startup, the Plan Executor (PE) 808 notifies the Plan Man- 
ager 804 that the plan is started and sends data collection 
information to the machine interface 812 including a setup 
data collection and an observable data collection. 50 

A Data Collection Plan Management Component 
(DCPlan) 819 describes the data that is collected by each of 
the machine interface 812, sensor interface (not shown) and 
other interfaces that collect data. The Data Collection Plan 
Manager (DCPM) 820 is the component responsible for the 55 
creation and management of DC Plans. The DCPlan is a data 
structure used exclusively by the AddOnSensor Interface 
Component (not shown) and the Machine Interface Com- 
ponent 812. The DCPlan is defined by the Plan Execution 
Manager (PEM) 806 including specification of the data to be 60 
collected from a particular processing equipment and how 
the data is reported back to the PEM 806. 

The DCPM component includes two main objects: a 
Manager 820 and the DCPlan 819. The Manager 820 checks 
DCPlans out of the persistent storage and manages the 65 
memory used for DCPlans. The DCPlan is an object that 
contains a set of observables to be collected. The DCPlan 


also describes the capabilities of a data collector to carry out 
the data collection task stipulated in the DCPlan 819. 

The PE 808 then starts the machine. The Machine Inter- 
face Component 812 begins operating and sends a "machine 
started" signal to the PE 808. When the operation of the 
Machine Interface Component 812 is complete, the Machine 
Interface Component 812 sends a "machine finished" noti- 
fication to the PE 808. The Plan Executor (PE) 808 finds 
permanent stored data tags from the data store manager 809 
of the Data Store Component 810 and updates values in the 
permanent stored data. The PE 808 generates and sends a 
product run record 817 to the data history manager 815 of 
the Data History Component 816 and sends run data to the 
run record 817 of the Data History Component 816. The PE 
808 sends a plan completed signal to the Plan Manager 804. 
The PE 808 then terminates while the Plan Manager 804 
registers that the plan is complete. 

Referring to FIG. 9, a schematic block diagram illustrates 
an embodiment of an AddOnSensor Interface (SI) compo- 
nent 900, which is the proxy for an external sensor 902 
attached to any process equipment 904 controlled by the 
APC framework. The external sensor 902 may be a simple 
C++ stand-alone program acquiring data off a thermocouple 
wire 906, or a full-fledged LabVIEW application acquiring 
data using multiple transducers (not shown). Data acquisi- 
tion is typically performed using a combinations of data 
acquisition boards 908 and signal conditioning modules 910. 
The external sensor 902 communicates with the SI 900 in 
CORBA messages. A communication layer (not shown) has 
been created both in the form of a Data Link Library (DLL) 
that is loaded into LabVIEW and in the form of a C++ class 
template that is used in a C++ stand-alone program. The 
function of the communication layer, known as DAQ, is to 
provide external sensors a means of understanding CORBA 
messages. Hereinafter a DAQ-enabled external sensor 902 is 
simply referenced as "DAQ 902" in this document. 

The mapping between an SI 900 and a DAQ 902 is 
one-to-one in which multiple transducers can be connected 
to one process equipment. As long as the multiple transduc- 
ers are controlled by a single DAQ 902, one SI 900 is 
responsible for facilitating communications between APC 
framework components and the DAQ 902. The DAQ 902 is 
an application program written to acquire observable mea- 
surement from the process equipment using transducers. In 
some embodiments, the DAQ 902 is a simple C++ program 
or a lull fledge LabVIEW application using signal condi- 
tioning and data acquisition boards. The DAQ 902 commu- 
nicates with CORBA using either a communication layer 
DLL or a C++ template. 

The Plan Executor (PE) 808 shown in FIG. 8A sends a 
Data Collection Plan (DCPlan) to the SI 900 before data 
collection begins at the DAQ 902. The SI 900 parses 
information in the DCPlan and forwards only that informa- 
tion pertinent to DAQ 902, including Duration Plan, Sam- 
pling Plan, Reporting Plan, Observable, and Limits. In 
addition, the SI 900 forwards to the PE 808 the desired data 
acquired by the DAQ 902 in a predefined format and in a 
predetermined time interval. The format and time interval 
are specified in the DCPlan. 

Referring to FIG. 10, a schematic state transition diagram 
depicts a Data Collector 1000. The AddOnSensor (SI) 
Component 900 inherits the IDL interface from the Data 
Collector 1000. The Data Collector 1000 includes an Idle 
state 1002, a Ready state 1004, an Enabled state 1006, and 
a Collecting state 1008 that performs data acquisition. All 
states of the Data Collector 1000 are substrates of a com- 
ponent manager running state. 
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Referring to FIG. 11, a class diagram shows an embodi- 
ment of AddOnSensor class object model. The component 
object model diagrams use Object Modeling Technique 
(OMT) notations to represent the object classes and rela- 
tionships among the object classes. 5 

Referring to FIG. 12, a class diagram shows an embodi- 
ment of the communication layer DAQ class. FIG. 13 
through 15 are object collaboration diagrams showing vari- 
ous aspects of communication layer (DAQ) operation. 

Referring to FIG. 16 through FIG. 23, a plurality of 10 
schematic block diagrams show various aspects of data 
collection in the ACR 

AddOnSensor Class and Operation Specifications are 
described as follows. 

The AddOnSensor (SI) Class is inherited from classes is 
APCTypes_CapabilityProvider, APCComponent_ 
BaseManager, and APCDCInterfaces_DataCollector. 
Attribute: sensor_id :string 

Responsibilities: denotes the identification string one 

would use to communicate with 
SI. The identification string is issued as a return result to 

setup_data__collection ( ) call. 

Attribute: capability : string 2 5 
Responsibilities: describes the type of external sensor 

(DAQ) SI is communicating to, 
on behalf of other APC components. 

Attribute: buffer_seq :APCRunData: :RunDataSequence 30 
Responsibilities: stores the data collected by the external 
sensor. 

A Class DAQController is described as follows: 35 
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Responsibilities: returns the name of an item in the 
reporting plan data structure. 

Parameters: item idx :long 

Return Value: string 
Preconditions: SI is properly setup. 

Exceptions: SystemException 

Operation: rp__item_format 

Responsibilities: returns the format (data type) of an item 
in the reporting plan data structure. 

Parameters: item idx :long 

Return Value: ItemFormat 
Preconditions: SI is properly setup. 
Exceptions: SystemException 

Operation: rp_item_value 

Responsibilities: returns the value of an item in the 

reporting plan data structure. 
Parameters: item__idx :long 
Return Value: depends on the item format. 
Preconditions: SI is properly setup. 
Exceptions: SystemException 

The communication layer (DAQ) Class and DAQ Operation 
Specifications are, as follows: 

Attribute: capability :string 

Responsibilities: describes the type of external sensor 

DAQ is providing the CORBA 
communication layer for. 


Operation: trigger_observed 

Responsibilities: Informs the DAQ controller when DAQ 

observed a trigger described 
in the Data Collection Plan. 40 
Parameters: trigger_name :string 
Return Value: None 

Preconditions: DAQ Controller invoked setup_data_ 

collection method on DAQ 45 
Exceptions: SystemException 

A Class SlReportingPlan is described as follows: 

Attribute: num_item long 50 
Responsibilities: denotes the number of sequence items in 
the reporting plan. 

Attribute: rp :APCDataCollection::ReportingPlan 55 
Responsibilities: The reporting plan data structure. 

Operation: num_rp__item 

Responsibilities: returns the number of items in the 

reporting plan data structure. 60 
Parameters: None 
Return Value: long 
Preconditions: SI is properly setup. 

Exceptions: SystemException 65 
Operation: rp_item_name 


Operation: setup_data__collection 

Responsibilities: allows the SI to initiate the set up 

process at the external sensor. 
Parameters: dp :DurationPlan, sp :Samplin__ian, owl 

: Observable withLimitsS equence 
Return Value: capability :string 

Preconditions: Set up has not been performed before. 
Exceptions: SystemException 

Operation: enable_data_collection 
Responsibilities: allows the SI to enable the data collec- 
tion process at the external sensor. 
Parameters: None 
Return Value: None 

Preconditions: Set up has been performed. 
Exceptions: SystemException 

Operation: disable__data_collection 
Responsibilities: allows the SI to disable the data collec- 
tion process at the external sensor. 
Parameters: None 
Return Value: None 

Preconditions: Set up has been performed. 
Exceptions: SystemException 

Operation: started ata_collection 

Responsibilities: allows the SI to start the data collection 
process at the external sensor. 
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Responsibilities: returns the value of an item in the 
duration plan data structure. 

Parameters: item idx long 

Return Value: string 
Preconditions: set up process started. 


19 

Parameters: None 
Return Value: None 

Preconditions: Set up has been performed. 
Exceptions: System Exception 

Operation: stop data collection 

Responsibilities: allows the SI to stop the data collection 

process at the external sensor. 10 
Parameters: None 
Return Value: None 

Preconditions: Set up has been performed. 

Exceptions: SystemException 15 

Operation: unsetup data collection 

Responsibilities: allows the SI to Un-set up data collec- 
tion configuration at the external sensor, clean up is 
performed. 20 

Parameters: None 

Return Value: None 

Preconditions: Set up has been performed. 

Exceptions: SystemException 25 

Operation: get_daq_buffer 

Responsibilities: allows DAQ controller to retrieve data 
collected since the same method was called. 

30 

Parameters: None 
Return Value: DaqBufferSeq 
Preconditions: Set up has been performed. 
Exceptions: SystemException 

35 

Operation: daq_cap ability 

Responsibilities: allows the external sensor to inform 

DAQ about it's data acquisition capability. 
Parameters: capability string 40 
Return Value: None 
Preconditions: None 

Operation: num_dp_item ^ 
Responsibilities: returns the number of items in the dura- 
tion plan data structure. 
Parameters: None 
Return Value: long 

Preconditions: set up process started. 50 
Operation: dp item_name 

Responsibilities: returns the name of an item in the 

duration plan data structure. 55 
Parameters: item_idx :long 
Return Value: string 
Preconditions: set up process started. 

Operation: dp_item_format 60 
Responsibilities: returns the format of an item in the 

duration plan data structure. 
Parameters: item_idx :long 

Return Value: string 65 
Preconditions: set up process started. 
Operation: dp_item_value 


Operation: num_sp_item 

Responsibilities: returns the number of items in the sam- 
pling plan data structure. 
Parameters: None 
Return Value: long 
Preconditions: set up process started. 

Operation: spjtem name 

Responsibilities: returns the name of an item in the 

sampling plan data structure. 
Parameters: item_idx :long 
Return Value: string 
Preconditions: set up process started. 

Operation: spjtem_format 

Responsibilities: returns the format of an item in the 

sampling plan data structure. 
Parameters: item_idx :long 
Return Value: string 
Preconditions: set up process started. 

Operation: spjtem_value 

Responsibilities: returns the value of an item in the 

sampling plan data structure. 
Parameters: item_Jdx :long 
Return Value: string 
Preconditions: set up process started. 

Operation: num_observabIe 

Responsibilities: returns the number of observable in the 

ObservableLimitsSequence 
data structure. 
Parameters: None 
Return Value: long 
Preconditions: set up process started. 

Operation: observable_name 

Responsibilities: returns the name of an observable in the 

ObservableLimitsSequence data structure. 
Parameters: obs_idx :long 
Return Value: string 
Preconditions: set up process started. 

Operation: observable format 

Responsibilities: returns the format of an observable in 
the ObservableLimitsSequence data structure. 

Parameters: obs idx long 

Return Value: ObservableFormat 
Preconditions: set up process started. 

Operation: num_observable_limit 
Responsibilities: returns the number of limits in an 
observable, in the 
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ObservableLimitsSequence data structure. 

Parameters: obs_idx :long -continued 

Return Value: long #include<APCRunData.idl> 

Preconditions* set Up process Started M The APCDCInterfaces module defines the interface of a Data Collector 

H F ' 5 module APCDCInterfaces { 

// The Data Col lector interface is an abstract interface that is mixed 

Operation: limit name // with other interfaces to form a concrete interface. The concrete 

„ M . . c i* •* • // interface defines the state machine and state attributes for itself 

Responsibilities: returns the name of a limit in an ;/ and the te operations raise a system exception if 

observable, in the // the manager isn't running. 

ObservableLimitsSequence data structure. 10 typedef string Da taCo Hector id; 

typedef string DataMoniker; 

Parameters: obs_idx :long, limiLidx :long exception invaiidDCPian 

Return Value: string { 

string message; 

Preconditions: set up process started. } ; 

15 exception DCSetupFailed 
Operation: limit_format s { tring message; 

Responsibilities: returns the format of a limit in an }; 

Observable, in the exception DCUnsetupFailed 

ObservableLimitsSequence data structure. ^ string message; 

Parameters: obs_idx :lone limiLidx :long h 

exception InvahdDCId 

Return Value: LimitFormat { 
Preconditions: set up process started. ® trin S message; 

exception InvalidDCParams 

Operation: limit_upper_value 25 { 

Responsibilities: returns the upper value of a limit in an ^ nng messa S e > 

observable, in the exception DCStartFailed 

ObservableLimitsSequence data structure. { 

, string message; 

Parameters: obs_idx :long, limiLidx :long 30 } ; 

Return Value: depends on the limit format exception DCStopFailed 

Preconditions: set up process started. str ing message; 

}; 

^ A . -i * exception DCEnableFailed 

Operation: hmit__lowe revalue 35 { 

Responsibilities: returns the lower value of a limit in an string message; 

observable, in the } ; . , , „ ., , 

exception DCDisableFailed 

ObservableLimitsSequence data structure. { 
Parameters: obs_jdx :long, limiLidx :long ^ rin 8 message; 

Return Value: depends on the limit format 40 exception invalidMoniker 
Preconditions: set up process started. ( 

string message; 

}; 

Operation: daq_setUp_COmplete exception RetrieveDataFailed 

Responsibilities: allows the external sensor to inform 45 Ling message; 

DAQ the success or failure of the set up process. } ; 
Parameters: success boolean interface DataCollector 

Return Value: None DataCollectorld setup_data„collection( 

Preconditions: Set up process has Started. cn , . in APCDataCollection::DCPlan dc_plan 

1 r 50 ) raises ( 

InvaiidDCPian, 

Operation: next_action DCSetupFailed, 

APCTypes::SystemException 

Responsibilities: allows the DAQ to relay messages from ) ; 

SI to external sensor. This is required only when void unsetup_data_coiiection ( 
external sensor does not provide callback capability. 55 in DataCollectorld dc_id 

) raises ( 

Parameters: None invaiidDCid, 
Return Value: string DCUnsetupFailed, 

APCTypes::SystemException 

Preconditions: Set up process was successful. V oid enabie_data_collection( 

irn in DataCollectorld dc_id 

) raises ( 

InvaiidDCid, 
DCEnableFailed, 
APCTypes : :SystemExcep tion 
void disable_data_collection ( 


A Data Collector IDL is described as follows: 


#ifndef_^\PCDCInterfaces_idl_ in DataCollectorld dc_id 

#define_APCDCInterfaces_idl_ 65 ) raises ( 

#include<APCDataCollection.idl> InvaiidDCid, 
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-continued 


-continued 


); 


DCDisableFailed, 
APCTypes::SystemException 


void start__data_collection ( 

in DataCollectorld dc_id 
) raises ( 

InvalidDCId, 

DCStartFailcd, 

APCTypes::SystcmException 

); 

void stop_data_col1ection ( 

in DataCollectorld dc„id 
) raises ( 

InvalidDCId, 
DCStopFailed, 

APCTypes : :SystemExcep don 

); 

APCRunData::RunDataSequence retrieve_data ( 
in DataCollectorld dc_id 
in DataMonLker moniker 
) raises ( 

InvalidDCId, 
InvalidMoniker, 
RetrieveDataFailed, 
APCTypes : :SystemException 

); 

}; 

}; 

#endif 


{ 

}; 

5 #endif 

A DAQ Controller IDL is described as follows: 
#ifndef_^APCDAQController_idl_ 
#define_APCDAQController„idl_ 
#include<APCRunData.idl> 
// The AddOnSensor interface . . . 

10 interface APCDAQController 
{ 

void trigger observed 

( 

in string trigger_name 
) raises 
15 ( 

APCTypes::SystemException 

); 
}; 

#endif 

A DAQIDL is described, as follows: 

#ifndef_APCDataAcquisition_idl_ 
#define_APCDataAcquisition_idl_ 
#include<APCTypes.idl> 
#include<APCDataCollection.idl> 
#include<APCDAQController.idl> 
// The DAQ interface . . . 
module APCData Acquis lion 


20 


25 


A Data Collector Events IDL is described as follows: 


#ifndef_APCDCEvents_idl_ 
#define_APCDCEvents_idl_ 
#include <APCRunData. idl > 
#include < APCDCI n te rfaces. idl > 
module APCDCEvents 
{ 

struct DataAvailable 
{ 

APCDCInterfaces:: DataCollectorld id; 
APCDCInterfaces::DataMoniker moniker; 
APCRunData::RunDataSequencedata; 

}; 

interface DCPushConsumer: CosEventComm : :PushConsumer 
{ 

oneway void data_available 

in APCDCInterfaces::DataCollectorId id, 
in APCDCInterfaces ::DataMoniker moniker, 
in APCRunData::RuriDataSequence data 

}; 
}; 

interface DCProxyPushConsumer: 
CosEventChannelAdmin : :ProxyPushConsumer 
{ 

oneway void data_available 

( 

in APCDCInterfaces "DataCollectorld id, 
in APCDCInterfaces ::DataMoniker moniker, 
in APCRunData::RunDataSequence data 

); 
}; 
}; 

#endif 

An AddOnSensor Interface IDL is described, as follows: 
#ifndef_APCAddOnsensor_idl_ 
#define_APCAddOnSensor_idl_ 
#include < APCDCInterfaces. idl > 
#include <APCRunData.idl > 
// The AddOnSensor interface . . . 
interface APCAddOnSensor 
APCComponent::BaseManager, 
APCTypes-CapabilityProvider, 
APCDCInterfaces::DataCollector 


45 


50 


{ 

typedef sequence <float> SensorData; 
struct DaqBuffer 
{ 

string name; 

SensorData data_seq; 

APCTypes: :Timestamp time_stamp; 

}; 

typedef sequence<DaqBuffer > DaqBufferSeq; 
typedef string Capability; 
interface Data Acquisition 
{ 

Capability setup data collection 

( 

in APCDataCollection::DurationPlan dp, 
in APCDataCollection-SamplingPlan sp } 
in APCDataCollection::ObservableWithLimitsSequence owl 
) raises 
( 

APCTypes::SystemException 
void unsetup_data„collection 
( 
) 

( 

APCTypes::SystemException 

); 

void start_data_collection 
( 

) raises 
( 

APCTypes : :Sys temExceptio n 

); 

void stop„data_col lection 
( 
) 


( 

APCTypes::SystemException 

); 

void enable_data_col lection 
( 

) raises 
( 

APCTypes : :Sys temExceptio n 

); 

void disable_data_collection 


( 


APCTypes::SystemException 

); 

void set_con trailer 

c 
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-continued 


26 


in APCDAQController controller 
) raises 
( 

APCiypes::SystemException 

); 

DaqBufferSeq get_daq_buffer 
( 

) raises 
( 

APCiypes : :System_xceptio n 

); 


}; 

#endif 


25 


40 


A first task in the testing of distributed CORBA-based 
systems is a selection of a suitable set of tests. One option 
is the selection of a single test that tests all components. A 
more suitable approach is to identify a series of tests 
beginning with simple tests that exercise a small number of 20 
interfaces or components. Additional tests exercise combi- 
nations of components and interfaces until the entire system 
is tested. 

Initial tests most advantageously test interactions that 
involve only a few components such as tests of components 
that operate solely as servers and, thus, make no calls to 
other components. Even components that do not interact 
with other components involve some complexity since mul- 
tiple aspects are tested to determine correct operational 
scenarios, and to detect operations out of sequence, state- 
based tests, bad parameter values, and so on. A single test 
case is made up of multiple testing scenarios. 

Another technique for determining suitable tests of low 
complexity interactions includes an analysis of a small set of 
interfaces that are common across a large number of com- 
ponents. For example, all components may provide a com- 
mon infrastructure to activate component logging, log 
incoming requests and replies to a central server, and deac- 
tivate logging. An implementation of logging interfaces may 
be deployed in several components and tested against the 
logging service. 

A further technique involves writing of a test case with 
both normal and abnormal scenarios. An example of an 
abnormal scenario is a logging test in which the logger fails. 
A driver program is written to connect to the components 
and call a common logging interface of the components. 
After running the test, all components in the system support 
logging and provide a solid foundation from which to run 
other tests, since tracing and timing information remain 
available in the log. 

Still another test determination technique involves selec- 
tion of services that are used by several components in 
common. One example is selection of an event service, a 
naming service, a trader, or a registry service. Testing of the 
interactions between the components and the services is 
specified early in the process so that early identification of 
interactions and data values eliminates uncertainty in the 
design and results in a system that is more likely to meet 
specifications. 

Another test determination technique involves selection 
of use cases. A scenario is selected for each of the user- 
initiated events that result in the client sending out remote 
messages. The tests typically involve several components 
such as a client, any primary components with which the 
client interacts, any secondary components with which the 
primary components interact, and so on. If the client accepts 
input from the keyboard or mouse, testing tools may be used 


55 


to record and play back the user inputs to stress test the 
system for extended periods. Stress tests are useful but 
utilize a minimum of tracing information to determine what 
the servers are doing with the request once the request leaves 
the client. 

A further set of interactions to be specified in a test is an 
end-to-end test that exercises the entire system. In planning 
the end-to-end test, a tested with a harness for each of the 
components that participate in the test is used. Without the 
testbed, an end-to-end test cannot be performed until all 
components are developed. The testbed advantageously 
allows a component to be tested as soon as the component 
becomes available. 

Referring to FIG. 24, a schematic block diagram illus- 
trates an UML collaboration diagram. Collaboration dia- 
grams are diagrammatic tools for analyzing test cases. UML 
collaboration diagrams specify scenarios that make up a test 
case and identify the sequencing of interactions among 
components. Data handled in the UML collaboration dia- 
grams include information for starting and stopping the 
components in the test, initializing the components* internal 
state, and identifying the expected inputs and outputs from 
the test. The information is used to generate harnesses for a 
specific test scenario, set up a test, and determine whether 
the test is successful. 

Nodes in collaboration diagrams represent components 
that service incoming requests. The components operate as 
black boxes that hide internal classes. For integration 
testing, interactions among internal classes are unimportant 
and therefore not tested. Interactions among components 
that are tested. Prior to servicing a request, a component are 
initialized by possibly creating one or more objects, acquir- 
ing references to other objects, and registering with an 
Object Request Broker (ORB). An initialization section is 
included with the collaboration diagrams to control compo- 
nent initialization. A component that does not include an 
initialization section creates objects for each bind request 
that is received and registers, by component name, with the 
ORB. 

The edges in the UML collaboration diagram identify 
sequences of interactions and the values that flow from the 
interactions. The values are encoded using a notation such as 
an OMG exte realization service that is used to represent all 
OMG data types and exceptions. Many data types and 
references have a logical and simple encoding that is con- 
sistently defined and available at a set-up or initialization 
time, prior to run-time. Unfortunately, other data types 
include vendor-specific, opaque data that is confusing and 
only determined at runtime. An obscure, difiBcult-to- 
understand encoding does not create problems if compo- 
nents always return references to a local object. For 
example, in a simple case, an encoding can specify an 
expected data type and a returning harness simply creates 
and returns an object of that type. Unfortunately, the simple 
case is not always followed. Some systems specify that a 
component return a reference to an object in another differ- 
ent component. The return of a reference to a different 
component is allowed by encoding object references using a 
variable name of the form IOR:<object-id> that has an 
initialization specified by the test scenario. 

FIG. 24 represents an "Order Item" testing scenario that 
uses a factory 2402 to look up an object and apply methods 
to the object. The example uses a retail store object 2404. 
The test scenario orders an item from the store 2404. To run 
the test the retail store object 2404 and the factory 2402 are 
registered with the ORB. Then the retail store object 2404, 
the factory 2402, and a driver 2406 are started in a console 
window. 
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To stop the test, the retail store object 2404 and the factory 
2402 are stopped and then uninstalled from the ORB. 
Documentation of the illustrative test scenario includes data 
structures, as follows: 

1. Factory: :bind 

Format: Factory ptr bind(string) 

Request: {":Factory"} 
Reply: {IOR:factory} 

2. Factory: :lookup 
Format: Store_ptr lookup(string) 
Request: {":Sears"} 
Reply: {IOR:sears} 

2.1. Store::bind 

Format: Store_ptr bind(string) 
Request: {":Sears"} 
Reply: {IOR:sears} 

3. Store ::prices 
Format: PriceSeq prices( ) 
Request: {} 

Reply: {#({"Item_l", 12.99},{'Ttem_2", 5.99} 

4 Store::order 

Format: void order(Item) 
Request: {"Item_l", 12.99,3 }} 
Reply: {} 

Problems that span components are detected by reviewing 
the collaboration diagrams with developers of the compo- 
nents that participate in this test scenario. For example, if 
components are not threaded and the collaboration diagram 
shows a loop back to one of the previous components, a 
deadlock is detected and is repaired before developers write 
development code. 

If a collaboration diagram shows repeated calls from one 
component to access different data values in the same object, 
the different data values are encapsulated in a structure and 
retrieved in a single call. Performance is improved because 
the number of messages flowing over the network are 
reduced. If interactions involve a transfer of large amounts 
of data, performance is improved by encapsulating the data 
inside an interface and retrieved in chunks rather than all at 45 
once. Another option is to pass the name of a file back to the 
client and let the client use a distributed file system to access 
the values in the file. Problems, including the illustrative 
problems and other problems, are efficiently corrected by 
beginning a process by identifying, specifying, and review- 50 
ing test scenarios. 

Integration testing includes testing of each scenario of 
many in sequence until all are tested. Integration testing 
selectively proceeds from the top down, the bottom up, or a 
combination. 55 

Top-down testing uses harnesses to test interactions 
between components in a test scenario. In top-down testing, 
all the system interactions are tested using harnesses without 
waiting for implemented components. A component is tested 
with harnesses when available. The harnesses surround the 60 
component under test, so that a component that interacts 
with other components receives expected results. 

Bottom-up testing begins by testing lower-level 
components, then using lower-level test results to test the 
higher-level components in a sequence among increasingly 65 
higher-level components. Bottom-up testing is preferred for 
components that are not dependent on other components. A 
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single test program suffices to test independent components. 
Bottom-up testing reduces implementation of the harnesses 
for testing alone, since the tested components are used 
instead of harnesses. If development is staggered so that 
5 components become available in time to test components 
that use the available components, bottom-up testing elimi- 
nates a effort expended in developing the harness. Typically, 
both top-down and bottom-up testing are used. 

Execution of an operation is altered by the occurrence of 
io an exception. Before beginning the operation, the exceptions 
that affect an operation are specified in an "OMG IDL 
raises" clause. If exceptions are not specified, only OMG 
standard system exceptions are raised. Rather than relying 
on system exceptions, exception specifications are advanta- 
15 geously defined even for exceptions that directly correspond 
to an OMG system exception. Since the Object Request 
Broker (ORB) can produce system exceptions, if the opera- 
tion also produces system exceptions then a client process 
cannot reliably determine the source of a system exception. 
20 Some exceptions are reasonably anticipated although 
anticipation of all exceptions that different operation imple- 
mentations generate is difficult or impossible. For example, 
one can reasonably expect that if an account number is 
passed into the operation, a corresponding account may not 
25 exist so that specification of a NoAccountWithSpecified- 
Number exception is warranted. In contrast, exceptions such 
as running out of memory, the ability to communicate with 
another server, or the inability to open the persistent store are 
difficult to anticipate and are somewhat implementation- 
30 dependent. 

The OMG IDL for a system exception is: 
module Exceptions 

{ 

// Enums for the OMGs major codes. 
35 enum MajorCode{mc_UNKNOWN, mc_BAD_ 
PARAM, . . . , 

mc_OBJECT_NOT_EXIST }; 
// system exception 

exception SystemException(MajorCode major_code; 
40 string error_message;}; 

}; 

A guideline for user-defined exceptions includes two 
aspects: (1) specification of user exceptions (if any) that are 
anticipated based on the signature of the operation, and (2) 
a mandatory specification of one catchall exception for the 
error conditions that are implementation -dependent or can- 
not be anticipated. The guideline has several advantages. 
First, by defining user exceptions for anticipated exceptions, 
additional information is conveyed in the exception, and the 
exception is easily caught and handled. Second, by defining 
an all-encompassing system exception, unanticipated excep- 
tions are raised without redefining the IDL. Furthermore, 
exceptions raised by an exception are differentiated from the 
ORB system exceptions. 

For example, instead of generating the BAD_PARAM 
system exception to indicate that the application received an 
invalid parameter, an operation is configured to generate an 
Exceptions: :SystemException, a user exception that con- 
tains the same information as the CORBA exception. The 
Exceptions: :SystemException indicates that a bad parameter 
was passed and includes a message to identify the problem 
and some possible corrections. Message information asso- 
ciated to an exception is most advantageously supplied using 
a local file, possibly using an implementation-dependent 
minor code as a key into the file. 

IDL attributes are most advantageously defined through 
the usage of operations rather than by directly defining the 
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attributes since attributes are mapped into an operation in the 
programming language, but the operation cannot raise any 
user-defined exceptions. The implementation of the opera- 
tion may be overridden but the generation of a user-defined 
exception is not valid. For example, if one attempts to set an 5 
attribute to an invalid value, the operation generated for an 
attribute is dis advantageously limited to raise only system 
exceptions. A better course is define an accessor operation 
instead of a read-only attribute, and define an accessor and 
a mutator instead of an attribute. 10 

When creating a new IDL data type, a sequence for the 
type is most advantageously defined, particularly when new 
interfaces and top-level structs or unions are defined. Defin- 
ing a sequence enables the later definition of operation, 
possibly in other modules, to return a sequence of the 15 
defined types. Failure to define a sequence for a type leads 
to a high probability that IDL changes will be required at a 
later time. 

The OMG standard C++ mapping defines an alternative 
mapping for modules. Typically, modules are mapped to 20 
namespaces or classes so that the types contained in a 
module are referenced using a notation. For example, if 
module "Outer" contains a type called "Inner", the code 
would reference "Outer: :Inner." However if the compiler 
does not support namespaces or nested types, the mapping 25 
of modules would use an underscore ("__") notation and the 
code would be changed to reference all occurrences of the 
type with "Outer_Inner." Porting the code to different 
platforms in this case is therefore time-consuming and 
susceptible to error. To avoid the problem, macros are define 30 
that insert the "::" or the "__" between the module and type 
names. The macros are called when nested types are found. 
Enumeration literals have a similar problem. Some are 
nested in the name space (or class), and the alternative 
mapping defines enumeration literals at global scope. 35 

Instead of storing internal data members as native 
CORBA types; higher level abstractions such as those found 
in the Standard Template Library are used for storing and 
manipulating internal data values. The reason for using 
higher level abstractions is that the internal data values are 40 
to be kept in storage with a copy of the data passed to the 
Object Request Broker (ORB) upon a request by a client 
process. Copies of the data are to be made in any case so that 
little or no overhead is expended in copying the CORBA 
values into and out of higher level objects. The higher level 45 
objects are accessed and manipulated more easily using the 
higher level abstractions than by manipulating a native 
CORBA sequence. 

Memory-management rules are applied when developing 
distributed applications using C++. The component manager 50 
approach advantageously results in tighter control of core 
codes. A memory-management analysis tool, called "Purity" 
performs a strict adherent-to-memory "cleansing" to detect 
potential memory conflicts and problems such as dangling 
pointers and unfreed memory in all our components. The 55 
Purify tool identifies leaks in libraries or other code beyond 
the control of the application writers. 

In the illustrative embodiment of the APC, applications 
are supported cross-platform including support of HP/UX 
and Windows NT platforms. Cross-platform development 60 
problems are avoided by selecting tools that support cross- 
platform use initially. Tools selection is restricted based on 
the platforms supported by the tools and compatability 
between tools. 

Some embodiments of the APC system utilize load bal- 65 
ancing across the multiple process components. Software 
packages including Orbit-Isis and Orbit-OTM address load 
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balancing. Similarly, some embodiments of the APC system 
utilize programming packages, such as Orbit-OTS and 
Orbit-OTM, that improve robustness in a distributed object 
system. 

While the invention has been described with reference to 
various embodiments, it will be understood that these 
embodiments are illustrative and that the scope of the 
invention is not limited to them. Many variations, 
modifications, additions and improvements of the embodi- 
ments described are possible. For example, those skilled in 
the art will readily implement the steps necessary to provide 
the structures and methods disclosed herein, and will under- 
stand that the process parameters, materials, and dimensions 
are given by way of example only and can be varied to 
achieve the desired structure as well as modifications which 
are within the scope of the invention. Variations and modi- 
fications of the embodiments disclosed herein may be made 
based on the description set forth herein, without departing 
from the scope and spirit of the invention as set forth in the 
following claims. 
What is claimed is: 

1. A computer program product comprising: 
a computer usable medium having computable readable 

code embodied therein, the computable readable code 
including instructions that implement a process control 
software system capable of controlling a process hav- 
ing a plurality of devices communicating in a network, 
the devices including a metrology machine, a process- 
ing machine, and a controller, the process control 
software system including: 

a metrology machine plan routine capable of control- 
ling operations of the metrology machine, the 
metrology machine plan routine capable of generat- 
ing a human readable text describing activities to be 
exercised by the metrology machine and data to be 
collected and analyzed by the metrology machine; 
a processing machine plan routine capable of control- 
ling operations of the processing machine, the pro- 
cessing machine plan routine capable of generating a 
human readable text describing activities to be exer- 
cised by the processing machine and data to be 
collected and analyzed by the processing machine; 
and 

a strategy routine controlling operations of the 
controller, the strategy routine capable of coordinat- 
ing activities of the metrology machine plan and the 
processing machine plan that span multiple process- 
ing steps of the process. 

2. A computer program product according to claim 1 
wherein: 

the metrology machine is a pre-process metrology 
machine that measures a characteristic of a material 
prior to supplying the material to the processing 
machine, the pre-process metrology machine capable 
of generating a feed-forward measurement data that is 
communicated from the pre-process metrology 
machine to the controller; and 
the strategy routine utilizes the feed-forward measure- 
ment data as an input data to the controller, the strategy 
routine capable of determining a processing parameter 
based on the feed-forward measurement data that is 
applied to the processing machine and determines 
activities of the processing machine. 

3. A computer program product according to claim 1 
wherein: 

the metrology machine is a post-process metrology 
machine that measures a characteristic of a material 
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subsequent to processing the material by the processing 
machine, the post-process metrology machine capable 
of generating a feed-back measurement data that is 
communicated from the post-process metrology 
machine to the controller; and 5 
the strategy routine utilizes the feed-back measurement 
data as an input data to the controller, the strategy 
routine capable of determining a processing parameter 
based on the feed-back measurement data that is 
applied to the processing machine and capable of 1Q 
determining activities of the processing machine. 

4. A computer program product according to claim 1 
wherein: 

the process control software system includes software 
routines that are: 

distributed among the controller, the metrology 

machine, and the processing machine; 
object-oriented; and 

based on standards of Common Object Request Broker 
Architecture (CORBA), CORBA services, and 
CORBA facilities. 20 

5. A computer program product according to claim 1 
wherein: 

the process devices further include a database; 

the process control software system further includes a 

data store and a data history; 25 
the metrology machine is a pre-process metrology 

machine that measures a characteristic of a material 

prior to supplying the material to the processing 

machine; 

the metrology machine plan routine includes: 

a routine capable of directing the metrology machine to 

measure a material; 
a routine capable of receiving measurement data from 

the metrology machine; 
a routine capable of storing the measurement data in the 35 

data store for use in a processing step; and 
a routine capable of sending the measurement data to 

the data history. 

6. A computer program product according to claim 1 
wherein: 40 

the process devices further include a database; 

the process control software system further includes a 

data store and a data history; 
the processing machine plan routine includes: 45 

a routine capable of retrieving a process model from the 
strategy; 

a routine capable of determining a processing param- 
eter based on measurement data received from a 
metrology machine plan routine; 50 

a routine capable of sending the processing parameter 
to the processing machine and directing the process- 
ing machine to execute a processing activity; 

a routine capable of receiving a notification that the 
processing activity of the processing machine is 55 
complete; and 

a routine capable of sending determined parameters to 
the data history. 

7. A computer program product according to claim 1 
wherein: 60 

the process devices further include a database; 

the process control software system further includes a 

data store and a data history; 
the metrology machine is a post-process metrology 

machine that measures a characteristic of a material 65 

subsequent to processing the material by the processing 

machine; 


the metrology machine plan routine includes: 

a routine capable of directing the metrology machine to 

measure a material; 
a routine capable of receiving measurement data from 

the metrology machine; 
a routine capable of retrieving an old version of a 

process plan; 

a routine capable of executing a model update algo- 
rithm; 

a routine capable of storing the updated model in the 
data store for use in a processing step; and 

a routine capable of sending the updated model data to 
the data history. 

8. A computer program product according to claim 1 
wherein: 

the devices include a plurality of processing equipment 
devices; and 

the process control software system supports a run-to-run 
control scenario using model-based process control 
operating a plurality of the processing equipment 
devices, a result of material processing at a processing 
equipment device being passed on to a subsequent 
manufacturing step using feed-forward control and 
being used to influence future processing of the mate- 
rial. 

9. A computer program product according to claim 1 
wherein: 

the devices include a plurality of processing equipment 
devices; and 

the process control software system supports a fault 
detection and classification scenario using model-based 
detection and classification of problems occurring with 
a processing equipment device, data being collected 
from a processing equipment device being collected 
and analyzed using an idealized mathematical process 
model, a result of the analysis being used to detect an 
occurrence of a processing equipment device fault and 
to determine a type of the processing equipment device 
fault. 

10. A computer program product according to claim 1 
wherein: 

the computer usable medium is a communication signal 
transmitted over a communication channel. 

11. A computer program product comprising: 

a computer usable medium having computable readable 
code embodied therein, the computable readable code 
including instructions that implement a process control 
software system capable of controlling a process hav- 
ing a controller and a plurality of processing equipment 
devices and metrology machine devices communicat- 
ing in a network, the process control software system 
including: 

a plurality of process control framework components 
capable of controlling activities exercised by the 
processing equipment devices and controlling data 
collected and analyzed by the metrology machine 
devices; and 

the process control framework components being 
developed by an iterative process of a plurality of 
phases including analysis, design, implementation 
and deployment phases, the process control frame- 
work components being incrementally enhanced and 
having functionality increased in the plurality of 
phases. 

12. A computer program product according to claim 11 
wherein: 
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the process control framework components include a plan 
executor capable of controlling operations of a device 
such as the processing equipment devices and the 
metrology machine devices, the plan executor capable 
of generating a human readable text describing activi- 5 
ties to be exercised by the device and data to be 
collected and analyzed by the device; and 

the process control framework components implement a 
strategy coordinating activities of the plurality of 
devices that span multiple processing steps of the 10 
process. 

13. A computer program product according to claim 11 
wherein: 

the process control framework components are interop- 
erable by a user using a user interface, the user per- 
forming coordinating activities for operating the plu- 
rality of devices. 

14. A computer program product according to claim 11 
wherein: 

the process control framework components are substitut- 
able by a user using a user interface, the process control 20 
framework components being replacable or upgrad- 
able. 

15. A computer program product according to claim 11 
wherein: 

25 

the process control framework components are extensible 
by a user using a user interface, the process control 
framework components having a functionality that is 
extended to perform additional activities and special- 
ized for special activities. 3Q 

16. A computer program product according to claim 11 
wherein: 

the process control framework components are software 
routines that are: 

distributed among the plurality of devices; 35 
object-oriented; and 

based on standards of Common Object Request Broker 
Architecture (CORBA), CORBA services, and 
CORBA facilities. 

17. A computer program product according to claim 11 40 
wherein: 

the devices include a plurality of processing equipment 
devices; and 

the process control software system supports a run-to-run 
control scenario using model-based process control 45 
operating a plurality of the processing equipment 
devices, a result of material processing at a processing 
equipment device being passed on to a subsequent 
manufacturing step using feed-forward control and 
being used to influence future processing of the mate- 50 
rial. 

18. A computer program product according to claim 11 
wherein: 

the devices include a plurality of processing equipment 
devices; and 55 

the process control software system supports a fault 
detection and classification scenario using model-based 
detection and classification of problems occurring with 
a processing equipment device, data being collected 
from a processing equipment device being collected 60 
and analyzed using an idealized mathematical process 
model, a result of the analysis being used to detect an 
occurrence of a processing equipment device fault and 
to determine a type of the processing equipment device 
fault. 65 

19. A computer program product according to claim 11 
wherein: 


the process control framework components include: 
a plan execution component capable of controlling 
execution of advanced processing control strategies, 
plans, and process control scripts associated with the 
control strategies and plans, the plan execution com- 
ponent capable of interacting with other components 
of the process control framework components as 
dictated by the scripts to perform selected process 
control functionalities. 

20. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a fault detection monitoring component capable of 
supplying an information window into a current state 
and past states of processing equipment, information 
in the window including processing activity, alarms, 
and faults. 

21. A computer program product according to claim U 
wherein: 

the process control framework components include: 
a machine interface component for interfacing between 
an equipment interface and a process control repre- 
sentation of a fab tool, and for translating between 
equipment interface communications and a Common 
Object Request Broker Architecture (CORBA). 

22. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a sensor interface component for interfacing of sensor 
data acquisition Plug-in applications. 

23. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
an operator interface component for communicating 
between a wafer fab technician (WFT) and the 
process control system via a graphical user interface 
(GUI). 

24. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Document Management component for executing 
version control operations for extended implemen- 
tation by associated Document Management com- 
ponents including Data Collection Plan 
Management, Plug-in Management, and Plan Man- 
agement. 

25. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Data Collection Plan Management component for 
configuring and managing data collection plans, 
associated duration plans, sampling plans, and 
reporting plans. 

26. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Plug-In Management component for defining, 
importing, and managing process control Plug-In 
applications that are developed with tools that are 
external to the process control system, such as 
Matlab, Mathematica, and MatrixX. 

27. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Plan Management component for defining, 
configuring, managing, and defining usage of pro- 
cess control strategies, plans, and scripts. 
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28. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Sign-Off Management component for executing 
chance management, sign-off operations, and sup- 
porting other Document Management components. 

29. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Data Store component for storing and retrieving 
process control models and process control status 
data. 

30. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Data History component for storing an historical 
repository and archival of process control data for 
usage in off-line analysis. 

31. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Component Management component for executing 
administrative services, configuration services, event 
services, and state services for servers developed for 
the process control framework. 

32. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a System Management component for defining, 
grouping, installing, and managing components in 
the process control system. 

33. A computer program product according to claim 11 
wherein: 
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the process control framework components include: 
a Logger component for capturing activity and trace 
information for diagnostic and monitoring opera- 
tions. 

34. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Registry component for maintaining a centralized 
repository of component configuration information 
including setup values, system environment settings, 
and lists of dependent objects and event channels. 

35. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
an Events component for handling asynchronous event 
signals including receiving event signals from event 
suppliers and sending, event signals to event con- 
sumers that are decoupled from the event suppliers, 
the Events component supporting event "fan-in" and 
notification "fan-out". 

36. A computer program product according to claim 11 
wherein: 

the process control framework components include: 
a Trader component for handling service-based lookup 
for components to find other components that per- 
form a selected service. 

37. A computer program product according to claim 11 
wherein: 

computer usable medium is a communication signal trans- 
mitted over a communication channel. 
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[57] ABSTRACT 

A method and apparatus for predicting the spectral (wave- 
length -dependent) radiation transport in thermal systems 
including interaction by the radiation with partially trans- 
mitting medium. The predicted model of the thermal system 
is used to design and control the thermal system. The 
predictions arc well suited to be implemented in design and 
control of rapid thermal processing (RIP) reactors. The 
method involves generating a spectra] thermal radiation 
transport model of an RTF reactor. The method alto involves 
specifying a desired wafer time dependent temperature 
profile. The method farther Involves calculating an inverse 
of the generated model using the desired wafer time depen- 
dent temperature to determine heating element parameters 
required to produce the desired profile. The method also 
involves controjling the heating elements of the RTF reactor 
in accordance with the heating element parameters to heat 
the wafer in accordance with die desired profile. 
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METHOD AND DEVICE FOR PREDICTING 
WAVELENGTH DEPENDENT RADIATION 
INFLUENCES IN THERMAL SYSTEMS 

BACKGROUND OF THE INVENTION 5 

The instant invention is directed to a method and appa- 
ratus for predicting wavelength dependent radiation influ- 
ences in thermal systems, and more particularly for predict- 
ing such influences in systems including semitransparent 10 
mediums in a relatively simply manner such that the pre- 
dictions can be rapidly carried out. The predictive system 
includes a model which may be executed quickly on work- 
station class computing platforms and may be used, for 
example, in the design and control of rapid thermal process- 15 
ing (RTP) systems by permitting rapid comparison of alter- 
native reactor designs and physical models as well as 
real-time model-based control procedures. 

Prior attempts to simulate complex thermal systems such 
as RTP reactors have generally followed two approaches. In 20 
a first approach two-dimensional and three-dimensional 
finite-element or finite-volume approaches have been used 
to model the heat transport and coupled fluid flow in the 
reaction chamber. In such systems, the radiation exchange is 
handled through radiation view or exchange factors. Such 25 
approaches generally consider only gray-diffuse view fac- 
tors. One approach, described in Lie et al., "Simulation of 
Thermal Processing Equipment and Processes," Rapid Ther- 
mal and Integrated Processing //, Material Research Society 
Symposium Proceeding, 303 (1993), also considers specular 3° 
reflection in their exchange factors. Gray-diffuse view fac- 
tors are calculated by geometry. Typically, the specular 
exchange factors' are calculated using Monte-Carlo, ray- 
tracing software. Such a modeling technique is disadvanta- 
geous in that it is complex and requires a relatively long time 3 5 
to run. 

The second approach to RTP modeling is based on 
process control. In these efforts, the models consider only 
one-dimensional conduction in the wafer, with convective 
and radiative heat fluxes considered at the wafer surfaces. 
The radiation is computed in terms of geometric gray-diffuse 
view factors that couple the lamp system to the wafer. While 
such models may be run relatively quick on a computer, and 
are therefore suitable for use in designing the real-time ^ 
control algorithms, these approaches do not take into 
account non-gray wavelength-dependent radiation. 

Because radiation is an electromagnetic wave, an accurate 
model of radiative energy transport must include the influ- 
ences of spectral (wavelength-dependent) and directional 5Q 
factors. The conventional technique treats radiative heat 
transfer between surfaces as diffuse reflectors and diffuse 
emitters-absorbers. In this way, the problem of diffuse 
surface interchange is reduced to a geometric problem of 
determining the view factors between all interacting sur- 55 
faces, and the directional effects are elirninated. 

The values of surface radiation properties (emissivity, 
transmissivity, and reflectivity) depend on the wavelength, 
thermodynamic state (e.g., temperature and composition or 
mole numbers) and the morphology of the surface (e.g., 60 
surface roughness). In other words, the radiation emitted, 
reflected, transmitted and absorbed by a solid body depends 
on the radiative properties of the material, temperature of the 
body, viewing direction and the surface conditions. 

Typically, conventional attempts to solve the complexity 65 
of the radiative transport consider only wavelength-indepen- 
dent radiation (gray-diffuse). Alternatively, some kind of 


2 

indirect way to estimate roughly the wavelength-dependent 
effects is employed. These approaches are not satisfactory, 
since spectral emissivity plays an important role in the 
behavior of radiative heat exchange between materials. 

SUMMARY OF THE INVENTION 

It is therefore an object of the instant invention to provide 
a method and apparatus for determining, that is, accurately 
modeling or predicting, wavelength dependent radiation 
influences in thermal systems in a manner which can be 
implemented sufficiently rapidly to overcome the above 
mentioned drawbacks. 

Still another object of the instant invention is to use the 
method and apparatus of the instant invention to more 
accurately and rapidly design and control rapid thermal 
processing (RTP) systems by permitting fast comparison of 
alternative reactor designs and physical models as well as 
real-time model-based control procedures. 

To accomplish these and other objects of the invention, 
there is provided a system which includes a modeling 
apparatus for accurately characterizing time dependent spec- 
tral thermal radiation transport of a thermal system. The 
thermal system has a first portion having one or more 
heating elements, and a second portion separated from the 
first portion by a partially transmitting medium. The mod- 
eling apparatus includes: an input device for inputting 
characteristics of the thermal system; a memory connected 
to the input device for storing the thermal system charac- 
teristics, the thermal system characteristics including at least 
geometric parameters of the thermal system, a time depen- 
dent intensity profile of the heating elements and wave- 
length-dependent properties of the partially transmitting 
medium; a processing unit connected to the memory, the 
processing unit predicting a time dependant spectral thermal 
radiation transport characteristic of the thermal system based 
on the thermal system characteristics; and means for pro- 
ducing a characteristic model of the thermal system using 
the time dependant spectral thermal radiation transport char- 
acteristic. 

In accordance with another embodiment of the invention, 
there is provided a method of controlling a rapid thermal 
processing (RTP) reactor for processing a silicon wafer 
under a desired wafer time dependent temperature profile. 
The RTP reactor includes a heating element and a partially 
transmitting component separating the heating element from 
the wafer. The controlling method includes the steps of: 
generating in a computer a spectral thermal radiation trans- 
port model of the RTP reactor for given heating element 
parameters; inputting into the computer data specifying the 
desired wafer time dependent temperature profile; calculat- 
ing an inverse of the generated model using the data speci- 
fying the desired wafer time dependent temperature profile 
to determine heating element parameters required to produce 
the desired wafer time dependent temperature profile; and 
controlling the heating elements of the RTP reactor in 
accordance with the heating element parameters to heat the 
wafer in accordance with the desired wafer time dependent 
temperature profile. 

In accordance with still another embodiment of the inven- 
tion there is provided a method of designing a rapid thermal 
processing (RTP) reactor for processing a silicon wafer 
which will include at least one lamp heating element and a 
partially transmitting component separating the lamp heat- 
ing element and the wafer. The designing method includes 
the steps of inputting data into a computer corresponding to 
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a general design of the RTP reactor including at least the 
thermal transport characteristic of the partially transmitting 
component and the wafer and the general design of the 
thermal radiation characteristic of the lamp heating element; 
generating in the computer a model of spectral thermal 
radiation transport of the RTP reactor based on the input 
data; and selecting components for the RTP reactor based on 
the model. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The instant invention will be better understood from the 
following detailed description of embodiments of the inven- 
tion in connection with the accompanying drawings, in 
which: 

FIG. 1 illustrates an apparatus in accordance with an 
embodiment of the instant invention; 

FIG. 2 illustrates a rapid thermal processing (RTP) reac- 
tor; 

FIGS. 3A-3H illustrate effects of assumptions made in 
input parameters used by the apparatus of FIG. 1; 

FIG. 4 is a graph illustrating the results of the apparatus 
of the instant invention compared with actual experimental 
data; 

FIGS. 5A, 5B, 5C, and 5D are illustrated sensitivity to 
physical approximations in the apparatus and method of the 
instant invention; 

FIGS. 6A-6D illustrate sensitivity to additional physical 
approximations in the apparatus and method of the instant 
invention; and 

FIG. 7 illustrates an output of an inverse analysis of the 
instant invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 
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In accordance with the instant invention, a physical model 
of wavelength dependent radiation transport in a thermal 
system having particular characteristics is generated in a 40 
modeling apparatus, e.g., in a workstation or other comput- 
ing platform. An apparatus according to an embodiment of 
the instant invention is depicted in FIG. 1. In FIG. 1, a 
' modeling apparatus 101 is generally shown. As more fully 
described below, the modeling apparatus 101 generates a 
model of a thermal system sufficiently rapidly to permit the 
model to be used in design of the thermal system as well as 
in the development of control software for the thermal 
system using real-time feed back from the modeling appa- 
ratus 101. In other words, the modeling apparatus 101 may 
be used to develop a model of the thermal system 130 prior 
to construction, and the design may be tested using the 
modeling apparatus 101 for desired performance character- 
istics. Since the results of the modeling apparatus 101 can be 
generated very fast, many alternative design parameters may 
be considered in designing the system in a relatively short 
period of time. Because the modeling apparatus 101 con- 
siders the wavelength dependence of the radiation transport 
of the thermal system, the modeling apparatus 101 can be 
used to accurately construct systems requiring stringent 
temperature control. This is particularly useful in systems 
where the thermal system includes opaque and partially 
opaque elements interacting with the thermal radiation. 

The modeling apparatus 101 has a thermal system char- 
acteristic input section 102 for receiving input characteris- 
tics of a thermal system to be modeled from an input device 
103 which may include, for example, a keyboard, a mouse, 
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an interface to another computer platform, etc. The thermal 
system characteristics are stored in a memory 106 under 
control of the thermal system characteristic input section 
102. A processing unit 110 (e.g. a CPU) connected to the 
memory 106, uses the characteristics about the thermal 
system stored in memory 106 to predict the operation of the 
thermal system including the wave-length dependent ther- 
mal radiation transport in accordance with a modeling 
program 111. The operation of this system and the manner 
in which it develops a wavelength dependent thermal trans- 
port model will be further explained in connection with a 
more specific example of an RTP system provided below. 

The predictive model generated by the modeling appara- 
tus 101 is provided to an output section 112. The output 
section 112 may be connected to a monitor 114, for example, 
to display the results. Alternatively, the output could be 
provided to any number of output devices, such as a printer, 
plotter, etc. These results may be used in the design of a 
thermal system directly by comparing the model generated 
by the modeling apparatus 101 with a desired function or 
characteristic of the thermal system to be built. 

The modeling apparatus 101 of the instant invention may 
also be used to perform an inverse analysis to establish the 
boundary conditions or parameter values required to achieve 
a certain function of the thermal system. This allows the 
apparatus to be used to establish the appropriate process 
parameters and boundary conditions for the thermal system 
modeled. In accordance with the instant invention, the 
inverse analysis can be directly carried out by the modeling 
apparatus rather than using the conventional approach, 
which merely solves the direct problem repeatedly, in a 
lengthy and costly iterative process, to determine appropri- 
ate input parameters to achieve a desired result. In other 
words, in accordance with the instant invention, once a 
particular thermal process is modeled for a particular set of 
control parameters, the device may then be used to auto- 
matically obtain the necessary control parameters to achieve 
a desired result by providing the modeling apparatus with 
parameters corresponding to the desired result. 

To carry out the inverse analysis, the modeling apparatus 
101 includes an inverse parameter input section 104 also 
connected to input device 103. A user inputs into the 
modeling apparatus 101 parameters corresponding to 
desired results, e.g., desired temperature characteristics of 
the system, which are stored in memory 108. The processing 
unit 110, under control of modeling program 111, uses the 
previously generated model of the thermal system and the 
parameters held in memory 108 and derives or predicts 
particular control parameters to meet the constraints entered 
through the inverse parameter input section 104. This pro- 
cess is more fully described below in connection with the 
examples provided. 

In the above description, a general inverse analysis is 
carried out by providing specific parameters of a desired end 
result. Alternatively, dynamic optimization may be used 
rather than specifying the desired trajectories as specific 
constraints. In this manner, the desired results are specified 
as least-squares inequality constraints. For example, if the 
system were used in an RTP reactor to control the tempera- 
ture of a silicon wafer during a reaction process, as more 
fully described below, instead of requiring exact tempera- 
ture-time histories at certain points on the wafer (the general 
inverse analysis problem), the wafer would simply be 
required to follow a specified temperature trajectory within 
plus or minus 10 degrees and with no more than 5 degrees 
temperature variation within the wafer. 

Using the inverse analysis and/or the dynamic optimiza- 
tion of the instant invention allows the system to be used as 
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a powerful design tool. For example, the apparatus may be 
used to evaluate and understand trajectory feasibility and 
control authority. For example, if the system were used to 
design a nominal chemical vapor deposition (CVD) reactor 
which is to include a maximum heater power of 50 kW and 
is to be used to carry out a process that calls for a particular 
temperature ramp to the required process temperature, the 
inverse model produced by the instant invention can be used 
to provide power-time histories for the heaters (more fully 
described below). If the required power exceeds the maxi- 
mum available for the given design, then the desired trajec- 
tory is not feasible with that design. The constraints would 
either have to be relaxed "or an alternate design developed 
that provided sufficient "control authority." 

In accordance with another embodiment of the invention, 
as further illustrated in FIG. 1, the modeling apparatus 101 
can be used to develop real-time control, systems for a 
particular thermal system. Conventional modeling schemes 
run "open loop," that is, without feed back. Conversely, 
nearly all processing equipment is run under "closed loop" 
process control. Thus, such conventional modeling schemes 
are not adaptable to use in real-time base development of 
control routines. In accordance with the instant invention, 
the modeling apparatus 101 operates sufficiently quick 
enough to be connected in a closed loop fashion to a control 25 
system development tool 120. In most instances, the control 
system will be implemented on some sort of computing 
platform and the control program will be implemented in 
software. However, the instant invention could be used in 
connection with other types of control systems which are 
implemented in hardware, for example. The control proces- 
sor/development tool 120 is comprised of a computer having 
software development tools loaded thereon. The computer 
may also be used to control an actual thermal system 130. Of 
course, separate computers could be used for these two 
functions. When the modeling apparatus 101 of the instant 
invention is connected to the control system development 
tool 120, concurrent engineering of equipment design and 
control programs can be carried out In this manner, the 
thermal system may be modeled in the modeling apparatus 
101, and physically based simulations may be run under the 
control of the very same process-control software that would 
eventually be loaded into the actual controllers of the 
thermal system 130 being concurrently designed in real-time 
(i.e., on the time scale of the actual thermal process). 

As illustrated in FIG. 1, the modeling apparatus 101 is 
connected to the control system development tool 120 via an 
interface 116. In the control system development tool 120, a 
control program is loaded and run to control the thermal 
system generated by the modeling apparatus 101. The mod- 
eling apparatus 101 and interface 116 emulate or appear to 
the control program as an actual thermal system. When the 
control processor 120 is connected to an actual thermal 
system 130, the system operates in a closed loop. For 
example, the control processor 120 controls the thermal 
radiation source element in the system (i.e., the time/inten- 
sity characteristics) by providing control signals along line 
124. The thermal system 130 may include temperature 
sensors (not shown), the output of which is used to return 
actual measured data to the control processor 120 along line 60 
124. The control processor 120 uses the measured tempera- 
tures to adjust the control parameters. In conventional sys- 
tems, while the control program in the control processor may 
then be altered on the basis of the actual refined tempera- 
tures, since the thermal system is already constructed, the 
freedom to modify the thermal system design is significant 
limited. 
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In contrast, the instant invention can be used to concur- 
rently develop the control program and the actual thermal 
system 130 design. Via the interface 116, the modeling 
apparatus provides data to the control development tool 120 
which is seen as actual closed loop measured data. In other 
words, certain dependent variables in the model predicted by 
the modelling apparatus become the "sensors" (e.g., the 
temperature measurements returned to the control processor 
120) and boundary conditions in the model become the 
"actuators" (e.g., the power or temperature intensities of 
heater elements provided as characteristics via line 117), 
which are controlled by the control software in the control 
development tool. 

Since the two elements are connected by communication 
interface 116, the controller software and the physical model 
may be simultaneously executed on different computer 
platforms. In this manner, both the design of the thermal 
system (via the input thermal system characteristics pro- 
vided to the modeling apparatus 101) and the control system 
(by changing the control program software) may be concur- 
rently designed. Real time control program development can 
be carried out in the instant invention since the instant 
invention can rapidly generate an accurate model of the 
thermal system, including wavelength dependence. In other 
words, the modeling apparatus of the instant invention 
generates its model sufficiently quick enough, that it acts as 
though an actual thermal system. 

Below is provided a more specific example of an embodi- 
ment of the instant invention used to design and/or control 
a rapid-thermal-processing (RTP) reactor. RTP reactors are 
used in silicon-semiconductor fabrication and provide a 
convenient illustration of the principles of the instant inven- 
tion and the manner in which the various elements are 
constructed and used to resolve specific reactor-design and 
process-optimization problems. Specifically, RTP provides a 
convenient illustration of the effects of wavelength-depen- 
dent (spectral) merrnal-radiation transport. 

Spectral-radiation behavior is an important consideration 
in semiconductor processing equipment, especially in lamp- 
heated systems that have partially transmitting components 
like quartz windows and the silicon wafer itself. A cross- 
section of an RTP-reactor 201, is shown in FIG. 2. The 
window 202, separates the lamp housing 204 from the 
reaction chamber 206. The lamp housing 204 houses a 
number of lamp rings 205 which are individually controlled 
sources of radiant energy. A silicon wafer 208 is provided in 
the reaction chamber 206 and is supported by the support 
members 209 which are fixed to the inner walls 210 of the 
reaction chamber 206. In the modeling apparatus 101 (FIG. 
1), the window 202 and the wafer 208 are represented by a 
radial one-dimensional transient thermal energy equation 
that describes thermal conduction within the wafer 208 and 
window 202, convective heat transfer at top and bottom 
faces thereof, and thermal radiation exchange between the 
window 202, the wafer 208, and the other features in the 
system, including the lamp housing and reactor walls 212, 
210. The second component of the model is the spectral 
radiation model. In accordance with the instant invention, 
the complex radiation exchange between all the surfaces in 
the reactor, including internal reflections 214 within partially 
transmitting media (e.g. window 202) are taken into account 
by the modeling apparatus 101 (FIG. 1). The instant inven- 
tion considers the radiative energy transport in wavelength 
bands. The radiation model produced by the modeling 
apparatus provides net radiative fluxes to the top and bottom 
surfaces of the wafer 214 and window 202, as well as 
internal heating due to energy absorption. Coupling between 
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the components is accomplished via the radiative energy 
fluxes to the window 202 and wafer 208. 

In the instant invention, the differential-equation part of 
the model parameters is essentially one dimensional. The 
modeling apparatus 101 executes quickly, even when the 
processing unit 110 is implemented on workstation class 
computing platforms. Thus, the modeling apparatus 101 
quickly accounts for spectral-radiation effects, and, as 
described above, may be used in design and real-time 
control systems. 

In order to better understand the instant invention, the 
underlying principles used by the modeling apparatus 101 to 
produce a model of a thermal system will now be described. 
For radiation heat flux at each surface in the thermal system, 
radiative heat exchange in each wavelength band is treated 
individually. The contribution of all wavelengths are then 
integrated into a compound radiation energy. The processed 
spectral radiation model is fully three-dimensional in so far 
as the geometric view factors consider three-dimensional 
geometries. While complex geometries for the radiation 
exchange are considered, the overall processing is simplified 
by considering only one-dimensional energy transport in the 
wafer 208 and window 202. 

While the processing unit 110 (FIG. 1) treats spectral 
radiation exchange in great detail, it does not directly 
consider specular reflections. A diffuse reflector is a surface 
whose bi-directional reflectivity is independent of reflec- 
tance angle; and a diffuse emitter-absorber is a surface 
whose directional reflectivity (absorptivity or emissivity) is 
independent of incidence angle. The assumption of radiation 
diffusely emitting and reflecting surfaces is reasonable since 
many reflections and re-reflections within an enclosure tend 
to average out radiative nonuniformities even when there are 
very smooth surfaces in the enclosure. For many practical 
problems, the diffuse analysis is actually valid and will give 
satisfactory results. The assumptions of diffuse surfaces is 
not valid for the enclosure with very "irregular" geometry 
such as long, narrow cracks with smooth surfaces, which 
need to be treated as specular reflectors by special 
approaches, such as Monte-Carlo or ray-tracing methods. 

The processing unit 110, under control of the modeling 
program 111, calculates a model from the input parameters 
corresponding to the thermal system to be modeled by the 
modeling apparatus 101. The following discussion defines 
the underlying principles and calculations used by the mod- 
eling apparatus to calculate the exchange of radiant thermal 
energy. The principles described below are more fully 
described in Aili Ting, "The Influence of Wavelength-De- 
pendent Radiation in Simulation of Lamp-Heated Rapid 
Thermal Processing Systems" (2nd International Rapid 
Thermal Processing Conference, RTP '94, Round Rock, 
Tex., 1994) pp. 102-109, incorporate herein by reference. 

Net heat flux per unit wavelength X, per unit area at each 
surface is: 
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The incoming flux per unit for all opaque or non-opaque 65 
surface elements is described by a vector-matrix equation 
resulting from a thermal balance inside the reactor, as 


(^) 
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S, diag 7V(X)r'* S diag(E(X) e^T) 

where I is the identity matrix, T is temperature, S is the view 
factor matrix, S x is related to S and will be explained later, 
Re is the reflection matrix, and Tr is the transmission matrix. 
Planck* s spectral distribution of emissive power for a black- 
body is given as 


»(-U-)-0 


The reflection matrix R e (k) is diagonal matrix that rep- 
resents the fraction of incoming energy reflected as a result 
of multiple internal reflections, 

where p is reflectivity and t is transmissivity. For an opaque 
surface, R^(X)=diag p(X)=I-diag e(X), where e(X) is the 
emissivity. The transmission matrix T r (X) is a diagonal 
matrix that represents the fraction of incoming energy that is 
transmitted as a result of multiple reflections in a non opaque 
media, 


q-Cpfl.))) 2 ^) 
i-(p(X)) 2 (t(W 


T r becomes a zero matrix for an opaque surface. The 
absorption or emission matrix E is a diagonal matrix that 
represents the fraction of incoming energy absorbed as the 
result of multiple reflections in a non opaque media, 


tf-pft)X/-ifl)) 


E(X)=diage(X) for an opaque surface. Because p(X)-K(X)+ 
e(A)=l, the above expression satisfies the equation: 

S l isa matrix related to the view factor matrix S in such 
a way that (S^^KS)^. This provides a method to predict 
radiation exchange between surfaces separated by a semi- 
transparent material (i.e., quartz window 202). The sub- 
scripts j and j x represent surface elements on opposite sides 
of the RTP quartz window. 

Integrating over all wavelengths, the total heat flux to 
each surface is 


J o 


diagA{diagE<k) [7-5 diagR t {\) - 


S, diagT r (K)r l S - /} * AvUttfeiO. T))dk + 
diagAidiagEO^Ji [I - S(I - diageO^W'S - 7} * 

diagEO^Jd - F)aT* 
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where A is the diagonal matrix of surface element area, and 


07* J , 


is the fractional blackbody emission, and X max is the wave- 
length after which the surface becomes opaque, t=0, and 
e=constant. 

Numerically, the integrals are evaluated by using the 10 
conventional trapezoidal rule, 


i N-l 

AdX^-~ Z CA„ + (X^i-K) 
z n=l i 


15 


where N is the maximum wavelength grid number for A,^. 
The equation representing the vector of net radiative fluxes 
to all surface elements, Qr a JJ) can be interpreted physically 


10 


The radial conduction is represented by the discrete (finite 
difference) form of 


where A(r) is the cross-sectional area of the window 202 or 
wafer 208 and k(T) is the thermal conductivity. The discrete 
form consists of a tri-diagonal matrix multiplied by the 
temperature vector. Symmetric boundary conditions are 
applied at the center of the wafer 208 and window 202. 
Conducting or adiabatic boundary conditions are applied at 
the support 209 and wall 210 interface if there is a ring- 
support and radiation heat flux is applied at wafer edge if the 
wafer is supported by pins. A thermal contact resistance or 
radiation heat flux is applied at the wafer 208 and support 
209 interface for the ring-support. 

Convection at the top and bottom surfaces is represented 

by 


absorbed flux 


total incoming flux, including reflection and transmission 

^ s 

emission from all surfaces 


diagA diagE(X)[I - SdiagRM - SidiagT&)}-i SdiagEC^e^X, T)dX- 


diagA diag(E<toeu(k T))d\ 


emitted flux 


The above banded wavelength-dependent radiation model 
is general. Thus, the modeling apparatus 101 can be used to 
evaluate arid predict wavelength-dependent thermal trans- 
port in any dimensional thermal system. Radiation heat flux 
at surfaces generally provides the surface thermal boundary 
conditions of the system. Since the instant invention con- 40 
siders only one-dimensional (radial) thermal conduction in 
the wafer 208, support 209 and window 202, the thermal 
balance forms a one-dimensional partial differential equa- 
tion (PDE) system with radiation heat flux at the surface 45 
serving as a heat source term in the equation for the element 
on which the surface resides. The thermal balance also 
involves thermal convection at the surfaces of the wafer 208 
and window 202 due to flowing gas which forms another 5Q 
heat source term in the one-dimensional thermal energy 
equation. Therefore, the matrix-form .of the thermal energy 
equation for all elements of the wafer 208, support 209, and 
window 202 can be treated as ^ 

C ~^T = GVad< ^ + <^dCO + QconriD, 
Q'rUT) = Q^D + <£TXT) (+G5ST CO), 

60 

where C is the element capacity vector, C=pc p V, where p is 
the mass density, c p is specific heat, and V is the volume. The 
radiation contribution at the top and bottom surfaces is 
evaluated from the banded radiation model. The radiation 65 
heat flux at the wafer edge gives a boundary condition for 
cases without the wafer support 209. 


Q gom/ (T>-h(p,T)A a (r)Cr-T tas \ 

where A, (r) is the surface area, h(p,T) is the pressure- and 
temperature-dependent convection coefficient. is the 
temperature of the gas. The discrete form of the convection 
term consists of a diagonal matrix multiplied by a tempera- 
ture vector. 

As more fully described below, the modeling apparatus 
can be used to first model the spectral radiation transport in 
the RTP reactor 201 and then to receive a prescribed wafer 
time-dependent temperature profile and provide the neces- 
sary time-dependent lamp intensity control to achieve the 
proscribed profile. For this purpose, the instant invention 
treats the lamps 205 as a surfaces in the lamp housing 204. 
A relationship between the lamp temperature and the applied 
lamp power can be readily derived. The lamp power and 
temperature are related as follows, 

where P is the lamp 205 power, A is the lamp 205 area, a is 
the Stefan-Boltzmann constant, T is the lamp 205 tempera- 
ture and T waZJ is the chamber wall 210 temperature. For the 
simple case that the lamps are flat cylindrical rings at the top 
of the chamber, as illustrated in FIG. 2, the area of each lamp 
ring AsrcCRV-r 2 ,), where x 0 and r, are the outer and inner 
radii of the lamp ring, respectively. 

The above described PDE may be solved by modeling 
apparatus 101 using known techniques such as DASSL 
software described more fully in R. J. Kee, L. Petzold, A 
Differential/Algebraic Equation Formulation of the Method- 
of-Lines Solution to Systems of Partial Differential Equa- 
tions, Sandia National Laboratories Report, SAND82-8893 
(1986), L. R. Petzold, A Description of DASSL' A Differ- 
ential/Algebraic Solver Sandia National Laboratories 
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Report, SAND82-8637 (1982), and K. Brennan, S. L. 
Campbell, and L. R. Petzold, Numerical Solution of Initial- 
Value Problems in Differential-Algebraic Equations, New 
York: North Holland (1989), the contents of which are 
incorporated herein by reference. In general, the modeling 
apparatus uses a general method-of-lines approach to con- 
vert the PDE to an ordinary differential equation (ODE). 
DASSL is designed to solve stiff differential-algebraic sys- 
tems (DAE) of the form g(t, y, y')=0, rather than y'=f(t, y). 
DASSL is a variable-order method based on the backward- 
differentiation-formula (BDF) methods. DASSL uses error- 
estimation methods to choose a sequence of time steps that 
controls local truncation error. 

The modeling apparatus of the instant invention was 
tested for use in design and control of an RTP reactor as 
described below. In the examples provided, 1 1 radial ele- 
ments are used each to represent the wafer 208 and the 
window 202. 

The reactor 201 radius is 12.0 cm, the lamp-to-window 
separation is 4.9 cm, the window-to-wafer separation is 
0.165 cm, and the wafer-to-showerhead (located at the 
bottom of the reactor and not shown) is 3.43 cm. A quartz 
window 202 of thickness 12.7 cm is provided and a silicon 
wafer 208 of thickness 0.635 mm is provided. There are four 
lamp 205 rings at the top of the reactor having center radii 
of 2.223 cm, 5.08 cm, 7.84 cm, and 10.9 cm. Each lamp 205 
ring has a width of 1.5 cm. A graphite wafer support 209 
spans the distance from the wafer edge to the reactor wall 
210. The view factors for such a system can be calculated 
analytically. The modeling apparatus of the instant invention 
is capable of predicting radiation effects in three dimen- 
sional geometries for such an RTP reactor. 

The mass densities of the wafer 208, window 202, and 
support 209 are 2330, 2200, and 7801 kg/m 3 respectively. 
The thermal conductivity of the window is held constant at 
744.8 J/kg-K. FIGS. 3A-3H illustrate graphically the pro- 
portions of materials used in the test of the modeling 
apparatus. FIGS. 3A and 3B show the specific heats and 
temperature-dependent conductiveness for silicon and 
graphite. The band-dependent emissivity of stainless-steel is 
shown in FIG. 3C. The emissivity of the graphite support is 
fixed at 0.95. We use a fixed emissivity of 0.05 to represent 
the reflector material at the top of the chamber. We take the 
' emissivity of the lamps to be that of tungsten, c=0.45 or as 
a function of wavelength as shown in FIG. 3D. FIG. 3E 
shows the transmissivity and refractive index for quartz. 
This data can be used to determine the wavelength-depen- 
dent quartz emissivity, (in one test the quartz emissivity was 
determined to be 0.8 * (1-^0, in another it is fixed at (1-^-p) 
where reflectivity is taken as 0.05). The wavelength-depen- 
dent transmissivity of quartz is also shown in FIG. 3E. The 
wavelength- and temperature-dependent silicon-wafer emis- 
sivity is shown in FIG. 3F. FIG. 3G shows the wavelength- 
and temperature-dependent silicon-wafer transmissivity. 
FIG. 3H illustrates an approximation where the emissivity of 
the wafer is only a function of temperature. 

Each of the tests (simulations) carried out using the 
modeling apparatus 101 to predict the behavior of an RTP 
reactor used 14 bands that are defined to capture features of 
the wavelength-dependent material properties. Specifically, 
the bands were divided at wavelengths of 0, 0.17, 0.3, 0.4, 
0.6, 1.1, 2.3, 2.6, 3.2, 4.0, 4.2, 8.0, 15.0, and ~um. In spite 
of the fact that the window is effectively opaque beyond 4.2 
urn, contributions to the wafer response from the longer 
wavelengths can be observed. 

The output results of the modeling apparatus of the instant 
invention were compared to data from tests carried out on 
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actual RTP reactors, where step power changes were applied 
to individual lamp rings. FIG. 4 shows data from one such 
test compared to predictions output by the modeling appa- 
ratus 101 of the instant invention. In this test only zone two, 

5 the maximum power of which is 11 kW, was varied. From 
0 to 67 seconds 20% power was applied, from 67 to 127 
seconds the power was 30%, from 127 to 190 seconds the 
power was 40%, from 190 to 250 seconds the power was 
50%, from 250 to 324 the power was 60%, and from 324 to 

10 364 seconds the power was 70%. The initial temperature for 
the entire system was 300° C. The modeling apparatus 
maintains wall temperatures at 27° C. throughout, although 
there is some ambiguity about the experimental wall tem- 
peratures at the start of the tests. Further, the modeling 

15 apparatus applied no convective heat transfer on either the 
wafer 208 or the window 202. An interface resistance of 0.1 
W/m-K between the wafer 208 and the support 209 was 
used. 

As illustrated in FIG. 4, a comparison of the modeling 
20 apparatus 101 predictions to the wafer center (upper curve) 
and edge temperature as measured by wafer-embedded 
thermocouples shows strong correlation of actual behavior. 
Initially, there is an offset between the predicted and mea- 
sured temperatures, but the comparison improves near the 
25 operating temperatures of the RTP reactor. Some of the 
disagreement at early times is due to uncertainty about the 
starting conditions in the experiment. The test demonstrates 
a degree of agreement between the model predictions and 
the actual data which is quite satisfactory. Thus, the results 
30 of the modeling apparatus can be used with confidence to 
predict effects of various approximations in the radiation 
transport and to facilitate the design of actual thermal 
systems. 

FIGS. 5 and 6 illustrate radial temperature profiles in the 

35 wafer 209 at an instant in time. These profiles were gener- 
ated using the modeling apparatus 101 to demonstrate the 
sensitivity of the modeling apparatus 101 to physical 
approximations. In other words, the modeling apparatus was 
used to predict the spectral radiation transport for a number 

40 of different thermal system characteristics. In each of the 
illustrated profiles, the input power settings were the same. 

FIG. 5A illustrates the effect of allowing the silicon wafer 
208 to be semitransparent, permitting transmission of the 
medium wavelength energy at low temperature. FIG. 5B 

45 compares input characteristics using a full wavelength- 
dependent window and a window with constant emissivity 
and wavelength dependant transmissivity. FIG. 5C illus- 
trates the effect of banded wavelength radiation at the 
stainless-steel reactor-chamber walls 210. FIG. 5D contrasts 

50 the difference between the cases with and without convec- 
tion at the wafer 208 surface. 

FIG. 6A compares single band and banded wavelength- 
dependent radiation. FIG. 6B compares conducting and 
insulated boundary conditions at the wafer support 209 and 

55 wall 210 interface. FIG. 6C illustrates normalized radiation 
heat fluxes over the wafer 208. FIG. 6D illustrates the 
normalized, banded wavelength-dependent, incoming heat 
flux to the top surface of the wafer 208 center. 
FIGS. 5 and 6 illustrate the effect that different approxi- 

60 mations have on the predicted wafer temperature. The 
magnitude of temperature differences depend on the radia- 
tive properties applied for the different cases. The fluxes 
illustrated in FIGS. 6C and 6D provide qualitative and 
quantitative views of how radiative heat is distributed on a 

65 wafer and over wavelength. Further, they illustrate how the 
effect of varying the input characteristic which corresponds 
to varying the proposed design of the RTP reactor can be 
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immediately observed in the output of the modeling appa- 
ratus. 

Using the above example of an RTP reactor, an example 
of how the inverse analysis can be implemented in the 
modeling apparatus of the instant invention is described. The 5 
transient trajectory of the wafer temperature is input into the 
modeling apparatus 101 as inverse parameters. Using these 
parameters, and the previously generated model, the lamp 
power trajectories required to meet the desired wafer tra- 
jectory can be calculated by converting the parabolic initial- 10 
boundary value problem into a differential-algebraic prob- 
lem. 

In the four-lamp-zone reactor illustrated in FIG. 2, the 
desired temperature trajectories at four points on the wafer 
208 are specified. In addition to the residual equation 15 
resulting from the energy balance at each point on the wafer 
208, as obtained from the initial prediction of the modeling 
apparatus, the specified trajectory introduces a new residual 
equation, F-Ty-T^/t). Since there are now two residual 
equations at four points on the wafer (the energy-equation 20 
residual and the trajectory constraint), the problem would be 
mathematically over specified unless new dependent vari- 
ables were introduced. The modeling apparatus 101 selects 
the lamp powers as the needed dependent variables. Thus, 
rather than specifying the lamp powers as parameters or 25 
boundary conditions (the direct problem), the modeling 
apparatus 101 determines, as a function of time, the required 
lamp power input (the inverse problem) and outputs the 
results. 

The direct problem can be solved without difficulty by a 30 
variety of methods, including the method-of-lines. The 
inverse problem, however, can cause great difficulty for 
traditional computational methods. One problem is that most 
ordinary-differential-equation software requires problem 
specification in the "standard form/' where each residual 35 
equation must contain the time derivative of a dependent 
variable. The trajectory constraint equations do not fit that 
form. The algorithms that underpin the DASSL software can 
handle the problem specification and the solution, however, 
for the above described problems. 40 

FIG. 7 illustrates the output results of an inverse operation 
of the modeling apparatus 101 of the instant invention. The 
specified wafer trajectory 702 (shown as a heavy line), and 
the derived required lamp powers 704, 705, 706, 707 are 
shown as a function of time. As expected the lamp powers 45 
increase initially to drive the wafer temperature up accord- 
ing to the trajectory. After peaking at about 5 seconds, 
however, the lamp powers decrease even though the wafer 
temperature continues to increase. This behavior is caused 
by the fact that the sUicon-wafer-irifra-red-transmissivity 50 
changes rapidly around 600° C. from relatively high trans- 
mission to essentially opaque. Thus, because the radiation is 
coupled more effectively to heat the wafer, the lamps must 
reduce power to maintain the desired wafer trajectory. 

As illustrated in FIG. 7, the inverse output can be used to 55 
provide control parameters in terms ofttimes and intensity 
for powering the heat lamps. In other words, for a desired 
wafer-temperature ramp, the inverse analysis predicts the 
required lamp power or cooling capacity. If the required 
lamp power exceeds that available in a given design, then 60 
the trajectory is infeasible, regardless of the controller 
strategy. Thus, the reactor must be redesigned or a less- 
aggressive trajectory considered Inverse analysis also pro- 
vides information on "control authority," which relates to the 
ability of the actuators to respond quickly enough. Lamps 65 
typically have very fast response time, but resistive heaters 
or cooling systems may not have the dynamic response 


14 

needed to accomplish certain trajectories. This information 
can be used to specify actual reactor designs and as feedback 
in developing control programs. 

The instant invention has been described above in con- 
nection with specific embodiments. The principles of the 
invention arc not so limited. Many variations on the uses of 
the instant invention will be apparent from the preceding 
disclosure. Accordingly, the invention is only limited by the 
appended claims. 
What is claimed is: 

1. A method of controlling a rapid thermal processing 
(RTP) reactor for processing a silicon wafer under a desired 
wafer time dependent temperature profile, the RTP reactor 
including at least one heating element and a partially trans- 
mitting component separating the heating element and the 
wafer, the method comprising the steps of: 
generating in a computer a spectral thermal radiation 
transport model of the RTP reactor for given heating 
element parameters; 
inputting into the computer data specifying the desired 

wafer time dependent temperature profile; 
selecting components for the RTP reactor based on the 

generated model; 
calculating an inverse of the generated model using the 
data specifying the desired wafer time dependent tem- 
perature profile to determine heating element param- 
eters required to produce the desired wafer time depen- 
dent temperature profile, 
wherein the selecting step selects the components for the 
RTP reactor to meet control parameters indicated by the 
inverse of the generated model; and 
controlling the heating elements of the RTP reactor in 
accordance with the heating element parameters to heat 
the wafer in accordance with the desired wafer time 
dependent .temperature profile. 

2. A method as recited in claim 1, wherein the inputting 
step comprises the steps of: 

selecting a number of prescribed locations in the wafer; 
and 

assigning each of the prescribed locations a corresponding 
temperature time dependence as the data specifying the 
desired wafer time dependent temperature profile. 

3. A method of designing a rapid thermal processing 
(RTP) reactor for processing a silicon wafer, the RTP reactor 
including at least one lamp heating element and a partially 
transmitting component separating the lamp heating element 
and the wafer, the method comprising the steps of: 

inputting data into a computer corresponding to a general 
design of the RTP reactor including at least a thermal 
transport characteristic of the partially transmitting 
component and the wafer and a general design of the 
thermal radiation characteristic of the lamp heating 
element; 

generating in the computer a model of spectral thermal 
radiation transport of the RTP reactor based on the 
input data; 

selecting components for the RTP reactor based on the 
model; 

inputting data corresponding to a desired time dependent 
temperature profile of the wafer to be processed in the 
RTP reactor; 

storing the data corresponding to the desired time depen- 
dent temperature profile in a memory; 
retrieving the stored data and utilizing the computer to 
calculate an inverse of the model to obtain control 
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parameters for the heating element necessary to heat 
the wafer in accordance with the retrieved data; and 
providing a control portion to control the heating element 
based on the control parameters obtained from the 
inverse of the model. 5 

4. A method as recited in claim 3, further comprising the 
step of utilizing the computer to calculate an inverse of the 
model, wherein the selecting step includes the step of 
selecting components for the RTP reactor to meet control 
parameters indicated by the inverse of the model. 10 

5. A method of designing a rapid thermal processing 
(RTP) reactor for processing a silicon wafer, the RTP reactor 
to include at least one lamp heating element and a partially 
transmitting component separation the lamp heating element 
and the wafer, the method comprising the steps of: 15 

inputting data into a computer corresponding to a general 
design of the RTP reactor including at least the thermal 
transport characteristic of the partially transmitting 
component and the wafer and the general design of the 
thermal radiation characteristic of the lamp heating 20 
element; 

generating in the computer a model of spectral thermal 
radiation transport of the RTP reactor based on the 
input data; and 

selecting components for the RTP reactor based on the 
model; 

utilizing the computer to calculate an inverse of the model 
to obtain control parameters for the heating element 
necessary to heat the wafer in accordance with a 30 
desired time dependent temperature profile of the wafer 
to be processed in the RTP reactor; and 

providing a control portion to control the heating element 
based on the control parameters obtained from the 
inverse of the model, 35 

wherein the selecting step includes the step of selecting 
the components for the RTP reactor to meet the control 
parameters indicated by the inverse of the model. 

6. A method as recited in claim 5, wherein the utilizing 
step comprises the steps of; 

selecting a number of prescribed locations in the wafer; 

assigning each of the prescribed locations a corresponding 
temperature time dependance; and 

determining the control parameters for the heating ele- 45 
ment as a function of the corresponding temperature 
time dependance constrained by the model of the 
spectral thermal radiation transport of the RTP reactor. 

7. A system including a modeling apparatus for accurately 
characterizing time dependent spectral thermal radiation so 
transport of a thermal system, the thermal system including 

a first portion having one or more heating elements, and a 
second portion separated from the first portion by a partially 
transmitting medium, the modeling apparatus comprising: 
an input device for inputting characteristics of the thermal 55 
system; 

a memory connected to the input device for storing the 
thermal system characteristics, the thermal system 
characteristics including at least geometric parameters 
of the thermal system, a time dependent intensity 60 
profile of the heating elements and wavelength-depen- 
dent properties of the partially transmitting medium; 


40 


a processing unit connected to the memory, the processing 
unit predicting a time dependant spectral thermal radia- 
tion transport characteristic of the thermal system based 
on the thermal system characteristics, 

said processing unit producing a characteristic model of 
the thermal system using the time dependant spectral 
thermal radiation transport characteristic. 

8. A system as recited in claim 7, wherein the modeling 
apparatus further comprises: 

a second input device for inputting inverse parameters 
specifying a desired thermal transport characteristic of 
the thermal system 

wherein said processing unit is coupled to said second 
input and is configured to produce an inverse of the 
characteristic model, the inverse of the characteristic 
model indicating a characteristic of the thermal system 
which is necessary to produce the desired thermal 
transport characteristic. 

9. A system as recited in claim 8, wherein the desired 
thermal transport characteristic is a time dependent tempera- 
ture at a location within the second portion of the thermal 
system and the characteristic of the thermal system which is 
necessary to produce the desired thermal transport charac- 
teristic is a time dependent intensity profile of the heating 
elements. 

10. The system as recited in claim 7, further comprising: 
developing means coupled to the modeling apparatus for 

developing a control program for controlling the heat- 
ing elements of the thermal system, the developing 
means receiving from the modeling apparatus tempera- 
ture indications corresponding to a modeled tempera- 
ture at selected locations within the characteristic 
model of the thermal system and providing to the 
modeling apparatus the time dependent intensity profile 
of the heating elements on a basis of heating element 
control parameters indicated by the control program; 
add 

input means coupled to the developing means for modi- 
fying the control program on a basis of an output from 
the modeling apparatus. 

11. The system as recited in claim 10, further comprising 
interface means connected between the developing means 
and the modeling apparatus for controlling exchange of 
information between the developing means and the model- 
ing apparatus. 

12. The system as recited in claim 11, wherein the 
developing means and the modeling apparatus are simulta- 
neously run on separate computing platforms and the inter- 
face means emulates an actual thermal system in real-time 
using an output from the modeling apparatus for the devel- 
opment of the control program. 

13. The system as recited in claim 10, wherein the thermal 
system is coupled to the developing means, wherein the 
developing means receives actual real-time data from the 
thermal system which is used by the developing means to 
adjust the time dependent heating profile of the heating 
elements that is provided to the modeling apparatus, and 
wherein the system is a closed loop system. 
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3. Su-shing Chen, "AEMPES: An expert system for in-situ diagnostics and process 
monitoring/' See Office Action of February 7, 2008. 


ABWg&Att e*pm system tor 
Sv»mlogChsn 


A bstract , 

An expert - MEMm <Mvtnti< Electronic 

Mete rills Processing, Expert System) for ie-siui diagnostics 
aad process monitorial, is boiag developed. Tbieespcrt 
»y*L»m is a key compeacat ef the /ml*fJ>*«Af 
mmmmfm*Mmwimm mmmigummm* ************ which is 
proposed to iategrmte the mmuf»ttuna S Une with its 
simulator, la the expert system, there are Iw interrelated 
subsystem* - e eenrm/ netware* twby*un for adoptive 
pret«s» control, laooiUring. mad leerniag. aad m rafe- 
a**W subsystem for burnt* interface and high-level Al 
reesoaiaf* 


An intelligent manufacturing equipment architecture vat 
defined in U). IA 151 lt«H *o Idea W implemeat this 
architecture ves propped. It bu tve co«p«nc»u 

U! manufacturing shipment * shipment hardware 
and feasor* 

(2 > iotaliigeot #f pert workstation - a hybrid At/arura! 
at Ivor k wjKrt workstation, 

for the intelligent export workstation, we propose the 
philesopby of o hybrid AJ/nrurel network export 
workstation, lu mooel* eased reasoning scheme coe tains 
process models aad the equipment model, A neural 
network: simulation software U used to leare process 
models oad tbo equipment model (Sometimes, human 
expert knowledge is very useful to prescribe the network 
topology oo that the learaJaf is supervised)- A neural 
network hmrdwore emulates the process models and th* 
equipmsat model for adaptive aad engine process 
men liar in g aad control. A rule* based export system 
provides huo&D interface sad high-level decision support. 

We have discovered that a auxaufecturia« liao tea he 
integrated vita it* manufacturing liao simulator a tb» 
intelligent expert workstation level. An Intelligent export 
workstation pro video a llak between the meeufacturiag 
liao aad Mo simulator at tbo equipmeet module, la oataaco. 
the manufacturing liao is distributed into cluster* ef 
processing module*, each of which hoe aa iatollifeat 
expert verfcstatioa described above, At present, 
manufacturing (hardware) tine* oad their (software) 
simulators are separately functioning III. 

The erteaiiatioa of this pepor is as follows. la sacOoa Z, 
wflif iMportoat issues of siaau factories autoatation ara 
^sevssed. la soetloa X tao disiribatod AEMPES system Is 
described. We rsfer to 171 for a rolatsd result oa group 
lecbnetogr ia se^iceaeucior dstigo for atoaufaoturiag 
la seeuoa < ihe iaiellii«at *quip<a«et architecture is 
proposed, la sectiea % the ideas of iapissssaiUg ea 
iadtvidusl AJEMPE5 expert ororketatfeoa ere pyre to a led la 
eddiUoa la the aoural aetrork mclhodoJegy. qualitative 
slmuietioA. discussed la lot is also quhe useful la ths 
medei-bettd roasaaiai- la teetioa a, a aeuroJ aetvork 
softvaro - IJfttSE (latereeiivo lieoral Niiwerk Sijoolatioo 
Iaviroasxoat.1 is prossaiad. INNSE is a subset of tao export 
vorksiftjioii klors aotoilod MOdoliag rosulls of processes 
sad t^uipmem w«ll appear elsewhere. 

t MaawfKwHag AiumatU>fl 

la Moaufectorloi auloisaaoa. two o>e|or objectives art th» 
tight coupling of CAD/CAM/CAT aad the tale emtio a or a 

cm»i o«9coow 01 tt n m emu cee 


meaufecturiag line aad lie sjlouiletor HI. HI First. La 
ataaa&eturiax sjutomeiiea, the dosaga. eit-ftu fact u ring aad 
trsUag should aai be separate stages. There ere at least two 


til The flow 9 f the complete fabrieaMoa process reliee 
oa the tyachreoizaUea of aiaay stops ia the three staaos. 

ill the tight coupling of three stages eaebies tao 
control, scheduling, aad maaageteenl of the complete 
febricstiea process to be saore" effective aad adaptive, 

The tight coupling requires a]j»v4ia»eau* caaeiasratioas of 
laaaufecturiag process desiga aad relevant device design, 
aa enormous endeavor. Al present, we do ant kiwrv exactly 
how to couple the throe sugos Ughtiy Bovovor, the 
starting point should he the modeling of equipment and 
processes aad the interface of seuipeieat/ process models 
with CAD tad CAT data, 

Secondly, the iataimlen ef a menu f* during line aad its 
siateleter Is esoeaUsl to autoaomoos ss on ufec taring 
systems, because the maaufacturlag itae simulator may be 
ceesitfared as the Heroin" 4 which m*U teles the coatrel 
iatelUgenco of a man ufactu ring system, the autonomous 
Cbumea lihil behavior of a saanufacutrlag system it 
maaifeeted by the level of integration of its "brtia" aad its 
"armeaad legs". 

The integrettoa enables adaptive seasor-drivea control. 
Usraiog. piaaaiag. and optimixotioo in production At 
present, vt do not have complete Integration or 
menu fectu ring lines with their simulators, The main 
nam is Ihe lac* ef a linking point betwoea the two, 

An eauipmsat model is the computational model of e 
semiconductor febricstion equipment, such et ea optics! 
liihog rephy stopper or en Ion implaater, Beceuto of the 
diversity of so mi conductor fsJbricsUon ec<uipmeat. their 
models should have on apea ere h hoc tare that it 
developable using rapid prototyping techniques 
aforeavor. thees models should bo multifunctional for 
assisting monuraeturing engineers, proees* eagiaeers aad 
operators. 


The logical architecture ef AEMPES depend* on the 
clustering of procose moderne and the iatereoanoctian of 
different clutter* A vacuum wafer trsaspert system is 
boiag developed for Latere** nectia« different clusters. 
Within etch cluster, precessiag modules are completely 
iategrsted ia the Brooks mech*fiism< Providing each 
processing module with aa expert system, we reeuire * 
ceatrel expert woHuftatloa composing of theee ino^viduol 
expert systems. The characterisation, testing oad 
diagaoetlci meMuremea! aad process coatroi are 
performed in the coatroi expert workstation. Indeed, this 
it a tightly coupled cluster- 

Nonthelsss, monitoring, central sad dlajnflSUts of the 
collectma of cluster suheysmms ere qu^us different. 
PUvskelly the local area network inter connect tag those 
subsystems Is ia parallel with the vacuum wafer transaon 
system. Due to the complexity or semiconductor process***, 
e'ceairelUed explicitly constrained aad minimally 
adaptive aparaach may act he edequat*. A distributed 
system contitting of iateractiag and ceeHmeuag cluster 
expert werketetioo is noeeeeery Tltu «/ ^^iSJ** U 
distributed Af systems are used ia the global AEMPE5. 
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control. A rule-based espert system »r»?i4t$ human 
interfere aad high-level decision support- 

Toe neural network tubsyitem which emulate* the 
pre case/ eouipmoot models serves m the "intelligent 
coetroUer* of the equipment medute The iaielljg.nl 
controller ftu reaJHimc tlaks with VLSI integrated Hnwn 
an* actuators of til* fabrication equipment. Thus, the 
men ufac luring line and it* sinuUcer ere tightly 
integrated la a cl#*e- loop mtoicr 


her<J*ere 


equipment 


lo ether clusters 


Distributed A! mechanism* are quite complax. Sen* of the 

t include: 


U) Accomodation of opto systems (systems with no 
complete represeetatien end with dim smic oily changing 
boundaries), 

(21 Combinatorial implosion, the possibility the* partial 
results et oa* c hMtif fin Hi* system ***y greatly constrain 
the peteaUaJ solution space ot another chaster, 

<3l Adaptability, the possibility (hat concurrent systems 
art inherently more adaptable than sequential systems. 

<4I Multiple perspectives, too need fo make different 
viewpoint* com latent, 

OJ Modeling tad aaelyai* of coordinating Intelligent 
agents oro different from ueoal methodologies. 


Often global system information is i 
male* lets! decisions because of Jnterdependency of 
different clutters There is no universal glebe! 
eptimiiation criterion. Ve propose tot rooperstire Par* to 
optimization, scheme latoitively. U it o scheme which 
optimizes multiple oblective function* of different 
clusters A solution to the Per tee opt imitation problem it 
oo« which dors not allow preferential treatment Of any 
individual cluster If « certain priority Jfcs used in lh« 
evernU factory planning. this school* muse o* modified* 
Other wise, the sequencing of processing tasks follows this 
scheme* 

Associated with this distributed Al approach, there ore Ok* 
issues ef dot* communication network si tad art aad 
detaoaae*. The SEMI Equipment Communications Standard 
(SEES) is extend* hie 10 this coo*. A distributed database fits 
naturally Sato the distributed Al setting la fact, k is a 
subset »r the distributed export system. 

1 ihttlliiial En&mmi Arehatreteri 

The intelligent equipment architecture consists of two 
compensate: 

(I) manufacturing equipment - equip me ot hardware 
snd SOnserSv 

it) loialligeat tspert weritaotien. - * hybrid Al/«eoral 
aeiwerlt tap art woritttaijoa. 

for the iolellijoai oapart vnrkstatLoa, we propose the 
philosophy of a hybrid Al/aooral aotwarh expert 
worfcsutieo, Its atedtkooood roosoalai achono coat* ins 
process aied«l$ m4 tbt equlpoitot eaodel. A o sural 
aotvorh fiaiMlatl*o ae ft vara la used to itara proeesa 
otedtts and the equipaseot saodtt A aeurol attwerk 
hardwart e as u later the proeaot noOoIt aad the e suit event 
model for adaptive mad oc-lin. prates* moat(oria« ood 


odopllvo 

OKtdtHag 

coNrol 

Koralfto 


(*putpme»il 6 N 


hwnan Interface 
high levol decisions 


neural 

network 

suotvslem 


rufc-b 
tubsystam 


mtarl I «gprst aqufipsntnt orchllacior* 


Clesa-loap feedhaelE control at each equipment module 
requires ia-preces? inspection, testiag aad 
characur Ration. Laser scan aikroocopr. electroo scan 
microscopy, el Up sees* try, aad inter ferrome try could 
prevtdo ia -pr ocees 4a ta for es traction of spatial 
iaformoti*a, *och ss Unewidtba aad thkkaess. aad » 
inspect particuiato-iaduced defttu. The tipert workstation 
ha* to detormia* whether a five* equipment poros&eter it 
withia certain specif ic at tons from the extracted feature 
values. We ceetd loveatliato mulUaensar fusion to thtt 
more complete spatial information id obtained, 
Furthormor*. electrical C-V aaaoaerotoeaU ore fuaod with 
sensed imo#e oat*, and their spatial interpretatiens 

The learaini aad optimifcation cepahilhJos are supported 
by the neural network subsystem «f the intelligent export 
werkstatien. However, a neural aetwark system oloae can 
sot provide complete teltittoat to complex eaxieeertftg 
problem*. A hybri4 Al/aeural attvark expsrt *ytltm 1* 
proposed hero to capture manufacturing haawltdd*. to 
perform adaptive control, aad to make pUaaiaf tad 
decision support, laloractiaf with the aaauftctursdK 
simuleter- 


Hnt 


tntelHotfii 

•aptrt 

woricstolkm 


mtmjtoctur inQ lint 


lnl*9r«tb» of aswvufackriftfl 
Mae and lie sunuletor 
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mullteemar 
fusion of 
I moon 


Loser mm 
microscopy 
Electron *e#i 



CUip$©« etry 


£ Quip men* 


<* ifMPK tefcfcjjuM tmi Capital 

to each cluster. AEhSPES i> 19 capture the capability of 
experienced p races* engineer! fur diagnostic*, 
monitoring and control of lb* duller Of eouipmcat 
modulfi. Thm esperience i# integrated villi computer 
anerysi* capability and baaic model* of the underlying 
pby*U* ef lb* cluster of equipment module*. The 
knowJeu** re^uireil i* coded into AEMIfS fur assisting 
precess operators or autonomously menitor/ceotrol the 
fabrication processes 

la AIMFES. wo use tft« concept of modef-based masoning 
Model-based reasoning if mi etteasioa of rule-based eaport 
*y*i*m technology 13k H is a subacid of knowledge 
engineering that involve* building and analyzing; an 
explicit compuutieasl model of the structure, principles 
and behavior of a system. In * traditional nim~ba**d eepert 
*y»tcm. heuristics used by un export to tolve a panic him r 
problem m coded into the knowledge b**e. la n model* 
besed system, knowledge is representod explicitly in 
computational modi If. *fo4*t«bns*d reasoning is mer* 
flexible, because lb* **m* system model may V* used for 
different epplicetion? or n cluster espcrt workstation: 

DUgoostics, 

Sensor/actuator interface, 

CAP/CAT interface, 

HvnM operator intorfac*. 

Planning , 

Decision support 

Control, 

Analysis 

It is possible lo integrate different perspective* or various 
application* in a sing** model this ifleittMS the power of 
an expert system furthermore, model-based reasoning 
systeni may be extended and modified quite easily to 
reflect any cosnge in the processing and evomll 
msnufacturiag onvironmonl. Traditional rul*-be*ed 
reasoning system* eon only bo changed by rewriting a 
significant amount of code*. Meoel-baacd system* ore 
algorithm-based Algorithm* can be revised continuously 
in computational model* by human oijwrt or machine 
learning <u#ing both Al tad neural network approach**) 

Cenveaiioiiai model-baaed reasoning »y»toeeo are object* 
oritntod |^|. Siructwral oleei**i* of a model my include 

Concepts {modulee and seibmoetolos ) 
Object* (sensors, component* in a •uoea*dw*e> 
Attribute* <par aweter* Heaperaiure. volug*. oreeeure) 
Relatione < A i* a eoeapoiie*t of 8. B tea ftpbeyetoee «f C> 
Functions (thermal oaidatino, eleaainD 


For eaanple. in tbe appliraiion of dingnoatica, fubBllOfiS 
are re pre sea tad from tbe perspective of component fault* 
on tno ru net ions. Tbo valoo* of b component aurtbute 
determine wbetfaer a component i* normal or not. Simple 
program f can bo embodied In one* kroakable component 
to croat* a "te*l-ce*e generator^ tbat automates fa^lt 
anakyel* and simulation. 



Lookup Table 


Action Table 


Tb* ooject eriented tree* of modal-based roea^nlnji can be 
represented by neural notwork* CenTertoly. »nf^^ » 
neural netwerb* can bo roproaentoi by ****** 
in obNct-oritnUd forms. Tbia boa been eetablwbed m lb* 
irterXro So* loo (Ml nnd UUtL ^ J* f « 
nooral network modeling toebniono* lo4|. to* b«k 
p/opigaticn !0Cbni*»*>< o^iionM intornnt wiabioi are 
fntfV&eed and mod*l* inwnbrtac addnionaJ vnrinbloenro 
Uameo Altboogb tjb«e Yarlnblt* may not, immoosnl* 
physical interpretatioos. w* consider tb*m « «»*nu«l 
P^cess/eouipment paramemra So* tbe neat aoction far 
tome modeUng oinmplo*. 

ln«rn*tlv* Nourol Wotworlt Simolntinn f***™***?! 
limm* H * bUrarebicn* noa^l notwork *imul*Ur wiib 
Ui macrocoll* comirtwtod by o*nra ; U tapnbl* of ****** 
eowipment, proceaao*. and man of act urn g linos, nan ii 
capable of slmulauoa run a* flow of action notvnrk*. 
Ai CAD tool* for clrcuU design e ngineors, fliN&E fee a part or 
tbo manufacturing process design ooftwnr* environment 
in tbo intelligent oaport work*taiien described nbor* 

Each neural network model consists of * mi nf Input unto 
and output unit*, a sot or internal unit*. * irnnsUioo jruio, 
and a learning rule. Tnero m«y bo a* many layor* *r 
miornol untta a* w* vlin. 

tet us denete by (oU the input unit*, (vp tbo output units, 
and (wg) tit* internal unit*, Tno values In bo assumed are 
botwen 0 and 1 This roquircs a *cnUa« factor for each 
physical variabl* Tbo link weight* between the** anil* 
am nenotod by Aib end Ag|. indicating connection* botwoen 
input unit*, internat units and output unit*. Tbo link 
weinbt* assume value* between -I and ♦» A posiiiv* link 
weight indkatoa ealtaiory connoctlon. and a negative link 
voiibt indlcnto* tnhibiaory connoclion. 

For illu strati on, we discus* two eaample*. Tno first I* a 
neural network model of the thermal oaMation process- In 
1 13 L n power Jaw was proposed for tb* ** idstiea tbickno**: 

a-at* 


121 


iMObfli* 
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\ internal unit* 
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lw*i Between units 
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output mm 


where » end b we funcuc-fiB of the teaporftturc T ftnd the 
pressure p. end t ii tbe a. more detailed power law 
involve* with ih* initial thickness Iff Mid the initial time 
tg It «u shewn that the ^mr lew fit* All observed dam in 
liiirail esldatiea (131 Easily, we have modeled the 
fun CUM » ft and V M output WAiU of ft A««rei Ml*ifk with 
input uaila T, p, s& ( I*. Using • bock »rop«4JU4*n learning 
rata, vt can construct tb is iwivirk with to internal units 
within error rate of 1%, This network can predict tbe 
bchevlors of ft and b voder input values which have net 
been eiperimeatsd The thickness s cm eis* be determined 
for uaeiperimeated iaput valves, by «Hher the power law 
or m neural network of itself Cm is treeted ft* * function of T r 
p, sg. io> *» future work . we shall verify our result* witb 
esperimeatal data, tf successful, vt shell use thJ*aetwerk 
for multiple-stage oxidation analysis sad control 

Tbe second example is ibe neural network medeiiog of the 
B*t»*ri SWS W system. J* i» * e*n*in werer, "f** 11 *"* 
cassette, planar magnetron .puUerieg eyetaia. This model 
« ft first pba*e modeling result, la ike i*4er phase*, we 
plan to tacorporate esperl knowledge into the modeling 
process, result! og in mere sophisticated neural network 
«ode is. U the present phase, wo consider 2 Iapui units - 
power and fu pressure, sad 5 owtput uoiu - Aiumieum 
dspositioe rate, liW deposition rate, metal film 
sputter etch uniformity, end sputter etch rote. Of 12 
internal units, w© have cenatructed the nturn! notwork 
within error roto of t H-Tait roAkor iImIo Model »ro*tde» 
o book function of tbU s^oipMeot 

tn Utif pooor. vt bftve presented a framework of t*o 
iii4«m*int equieeaect ftrchiteciwre and ft noural network 
modeling toeibodelogy. Neurol network roprwHrnUtionj 
c»e »o trentlfttod ittlo tbe eonveoitionftt Al roftsonk»g 
i»ecnonUftfti for tfeveioplog tbo latoltigeoi up«n 
workstation - AEMPCS. Tbo prosoat stoti.acel etodehni 
tec ho i such os regression anoirsi* aad factorkol 
iSea^aa. do not novo U»i* cftpftbility Tb* mere ifttportant 
„ 3 u# U tno real-time, close-loop control in tbe intoiligant 
equipneet arcbilacUiro. Wo bft^o proposed tbs mi 
Aeural Aftiwuritft to serve as tbe controller fw|. 
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